Reference question
Our group works with a common application but we also individually work on Engines. Is there a configuration is Rails 3 that allows us to put Engine-related migrations files on a different folder?
The goal is to track our migrations in Git, but also separate migrations related to the common app from the ones for Engines.
You can actually name migrations whatever you want. Docs. I would suggest the following convention.
[DATE]_[ENGINE_NAME|CORE]_[DESCRIPTION].rb
There you go!
Related
I am following this tutorial on creating Rails Engines and I'm curious about whether or not I need to list all of my host's dependencies (I'm creating a Rails engine called admin inside a larger Rails application) inside the Engine's gem file (apparently the engine will be accessed via a gem). Why do I need to do this?
Also why does the engine need all of the host's migrations? Or does the engine just need the migrations relevant to the files that I'm moving over to the engine?
An engine should be completely independent from its host. It's isolated in code and data, and should be able to drop into any host and work the same way. That means the engine doesn't have any special knowledge of the inner workings of its host, and the host has no special knowledge of the engine's internals.
If your engine depends on a model called Admin, then it should include a migration template for creating an admins table and 100% of the code needed to interact with Admins. The migration template will be copied into the host's db/migrations folder and run alongside its other migrations. Don't add migrations to the engine itself, because it'll have no way of running them once it's inside a host. Remember: the engine cannot know anything internal to the host, including its database schema.
I strongly recommend you create and maintain this separation. It'll save you huge headaches in the future.
Within the engine, you need to include all dependencies and code for the engine alone. Do not add dependencies or code required for the host, because the engine isn't allowed to know about them.
This is harder than it sounds, but there are great examples of engines you can follow. Check out RailsAdmin and Devise for high-quality samples of code organization, data management, and testing.
Testing is important. In order for your engine to actually display pages or interact, you may need to include dependencies like Rails. You can do that, but make sure you add them as development dependencies to your Gemfile. See the above projects for examples of how to do this.
I recommend you build your engine outside your host project, because it'll force you to write tests that don't rely on the host app. If your engine is testable and works well on its own, it'll work great when you drop it into your host too.
We've been using rails_admin for a project for a year. It's good, but it would be preferable to have an admin interface that ran in a totally separate process from the main Rails app and from a completely independent code base. rails_admin has so many dependencies that upgrading it along with the main Rails app has proven brittle.
So the functionality we would need is just basic crud for the database tables, with a little bit of magic to make editing associations easier.
Are there any light-weight solutions out there for this? Bonus points for being lightweight & Sinatra-based rather than Rails-based.
I would look into git submodules or subversion externals. The way I've done something similar to this is to
List item migrate the models into a standalone ruby project.
put them in a 'core' subdirectory/module.
Create a new rails project just for administration.
Share the models between the 2 rails apps using an svn external of the 'core' directory into each project's app/models directory.
So we abstracted our models into a gem because multiple applications use the same model set. The trouble is performing creating and performing migrations. Because it is a gem we basically removed rails.
It can't perform rails g or rake.
If we try to keep the config and script folder which allows that, the other applications will complain when they use the models gem.
We're hacking around this by allowing one specific application to perform all migrations.
Perhaps the better question is: What is the best way to modularize common models such that you retain rails g and rake db:migrate?
I probably explained this poorly, please ask any questions.
Thanks,
Justin
Are you using version control? You could look into just using a git submodule for the models folder which would allow you to use rails generators on all applications and keep them all in sync. Basically a submodule is a git repository inside an existing repository.
The commands are simple as well, to get started look into this guide here overall it should help you reduce the complexity of your application.
We have a website using Rails 2.3.x, bundler, nginx, passenger and git, and would now like to use the same code to deploy a very similar site. Differences between the two will include:
Locale
Databases
Validations in some cases
Views in some cases
What is the best way to manage these differences while using the same code base?
Some ideas we've had:
Create new Rails environments, such as production-a and production-b and handle differences in the appropriate environment files. One potential problem is that many gems and plugins are hardcoded to look for production or development environments.
Use Passenger to set a global variable or use the domain per request to determine which context to use. The problem with this are rake tasks, cron jobs, etc that would not have access to this state.
Maintain two versions of the config directory. This would be inconvenient maintaining 2 versions of all the config file, many of which would be identical. Also, I'm now sure how to leverage git to do this correctly.
Any ideas, tips, or examples would be greatly appreciated! Question #6753275 is related but seems incomplete.
One solution I have used in a rails 2.3.x project was to convert the entire site to an engine. That actually is pretty easy, create a folder under vendor\plugins\ and move all the app stuff there. You can see an explanation for rails 2.3 here.
If needed you can even move all migrations and stuff there as well, and use a rake task
to run those.
Everything that needs to be overruled can then just be placed in the actual rails project using the engine. So you would have two rails-projects, with their own configuration, locales and some local overrules, and one big shared plugin/engine.
We used git submodules to keep the code in sync over different projects.
In rails 3 this is even easier, since the engine can now just be a gem.
Hope this helps.
I have several active record models in a rails app and I would like to extract these models into a gem so that I can easily use them in several web apps. The process seems pretty straight forward, except for passing along the configuration for the models. Do I:
Add the configuration yaml file to the gem, thus assuring the databases will always be the same across all apps - seems rigid, esp for testing and dev, though the databases for production will always be consistent.
Use the ActiveRecord hooks to look for a database.yml file in the config directory with the database defined? If so, which hooks should I use?
This is a stupid idea. If you have a better way to handle this, I'm all ears. I'd prefer not to copy and paste.
You should use the host rails app's database config. Your plugin or gem should contain just the database migrations, and a rake task to run them from the host rails app (e.g. myplugin:db:migrate)
If your models need some other configuration file, you should create a rake task (e.g. myplugin:install) to copy it to your host app's config directory. (This task can call the db:migrate task automatically as well.)
Why do you want to embed the database.yml file inside the gem? Each rails application should use it's own database.yml
I would put all the models into a plugin and include that in each rails application that needs the models.