Rails - defining data fields in the model itself

Question

Using rails 4, I'd like to model my entire data model in one place. As I understand, typically one generates the fields of each class through migrations or using a rails generate scaffold command and the associations between classes inside the model files. This feels a bit cumbersome and I wonder if there's not a way to have it all in one place. I wonder if the field definitions can be made in the model file. This will enable seeing and editing the entire model in one place - very helpful and compact for bootstrapping new apps that have more than little associations.

Answer 1

It depends what you're talking about, specifically. To directly answer your question

I wonder if the field definitions can be added in the model file

Unfortunately, there is no such method (at least none that I am aware of) to synchronize between your ActiveRecord::Base models, and the database. In short, this form of synchronization is done through the rails migration files.

The convenience of using the rails g scaffold command is that it creates for you the migration files, along with the controller, models, and testing classes all at once. However, you absolutely are not required to do any of this through the scaffolding; you can do so piece by piece if you desire. In the case of making a mistake in describing the fields, or needing to modify something, you'd simply write / generate a new migration file.

You can technically write whatever you want in the model, but it won't be reflected in the database unless you either (A) manually alter the database (bad idea), or (B) write or generate a migration file to alter the DB as desired (better idea).

Basically, to do what you're thinking, you would typically want to write / generate a migration. The migration, as you know, is essentially a script to alter the database in some fashion: add or remove columns, rename columns, create tables, etc etc.

Other than associations, there is no field information written in the model. When you load a record from the database, ActiveRecord (basically) builds the object with appropriate accessors / mutators. In short, whatever columns are defined in the database for that table / model is what your model object will contain.

In regards to your note about the associations being cumbersome when generating a scaffold, if you're referring to how Rails will only write the belongs_to portion of the relationship in the specified model, yes that can be a bit annoying, but I believe the reason is simply because that side of the relationship is the only side that can be accurately assumed; Rails doesn't know what kind of relationship you ultimately want to have. So you do indeed need to go and indicate the "other end" of the relationship in the related model (the has_many side, for example).

Hope my rambling helps.

EDIT

In regards to your question in the comments, I can't really think of any "shortcuts" or workflow suggestions at the moment. Honestly, I think the best workflow in this case is to try to make sure you have the model as "correct" as possible before you write anything.

Think of it this way: in a framework that can synchronize the model with the DB, you're basically doing the same thing as migrations anyways because they would have to execute the same kind of DB commands (alter table and such). The only difference is that (A) the Rails migrations are acting as a record of each change, and (B) the specifics of the migration are explicitly indicated. Not to mention, you have the freedom to do a heck of a lot more in the migration, or add some decision logic, etc.

In general, though it may look really huge and cumbersome, having a lot of migrations isn't a bad thing, necessarily. In fact, I'd even say its expected (especially for longer-lived systems). As I said, it shows a record of what happened along the way, meaning how the system evolved and changed. Additionally, they're useful when you need to deploy a change that should be picked up by other developers, and/or executed in production.

Just a note, if you're deploying for the first time in production, one common thing to do is to execute 'rake db:schema:load' to load the entire schema at once (no data, just the table structure). This tends to be much faster than running each and every migration. This is only for a first-time installations, though.

Another note, the above paragraph is also the reason why you don't want to put any seed information (meaning, don't create records) in the migration files. That's what your seed.rb file is for.

So in conclusion, I think the main point you can take away from this is that migrations are very much akin to the commit history of your version control system (GIT, SVN, etc). I don't know about you, but my commit history does have a lot of "Fixing bug A", and "Correcting bug fix from previous commit" etc, and though its weird, this is technically perfectly acceptable and perhaps somewhat expected in most cases.

Answer 2

Typically you would define the associations in your model and manage the model's database fields through migrations. Scaffolding is not the right solution for building associations between models. Scaffolding will build models, views, and controllers, so it can be overkill sometimes. Not to mention, when you use scaffolding you get full CRUD for every single scaffold you generate. It often adds more than you need.