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.
Related
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!
When a rails project grows a lot, you can find yourself having trouble with fixes for the data in the production database.
I have normally used migrations or specific rake tasks for this, but I was wondering if a system similar to migrations existed for keeping the database fixes and run them when needed.
I know you probably figured this out by now but there IS a gem for this... it is called datafix
https://github.com/Casecommons/datafix
basically you create a datafix, like a migration, and a spec for it, then you can run it as needed on the server.
The following gems can be also used for this purpose:
nondestructive_migrations
datafix
migrake
migration-data
data-migrate
I prefer nondestructive_migrations and datafix they are very similar - nondestructive_migrations simpler implementation building on rails migrations.
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.
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.
So I'd like to share models between two Rails apps and do not like the submodules solution (burned me in the past). I'm thinking about using gems to solve this and have this basically working:
Create a gem using jeweler (my_models)
Create a rails app with something in the Gemfile like:
gem 'my_models', :path => '../my_models' so you can avoid constantly packaging the gem, etc.
Use shotgun to constantly reload all the classes (otherwise you can't really edit my_models files without restarting the server/console each time.
So a few questions:
Shotgun is slow, is there a better way in Rails to reload just that one gem each time?
If my my_models ActiveRecord models have dependencies, I put them in my_models gems, will that cause dependency nightmares in my regular app?
What else am I missing on why this could be a bad idea?
If you use a VCS with submodules support (like Git) you could just put models into a different repository and make it a submodule of your Rails apps. That would give you an almost effortless code sharing - Rails wouldn't even know that you are cheating.