[Rails] Lets talk about migrations

[CompiledMonkey]

So I had some issues earlier on with migrations in rails. My initial thought was that the ruby file was run each time, recreating the tables and therefore using the schema as it was declared in the ruby file. I understand now that this isn't the case and it makes sense, otherwise you're losing all of your sample data.

So, each time I want to add/edit to my database, I need to create a new migration? Right now I want to add a column to a table, so I'll just use the migration command and go from there. Is that right?

[vgarcia]

Yes. Think of migrations as version control for your database. Each new file is a change, not necessarily an addition.

Also, if you wanted to cheat and run the full migration, you can set the version to 0 in the schema_info table before running your migration. Not that I really recommend this.

[CompiledMonkey]

Yeah, I spent a lot of time yesterday screwing around with migrations. I kind of cheated the system by deleting the tables in MySQL, running the schema_import migration command, and then running migrate again so it does everything from scratch. Of course, your way sounds much easier.

I think my only issue with incremental migration changes is seeing the full schema at once. I like being able to look back at a single migration file and seeing the database table as it should be in final state. I guess the schema.rb file (think that's the name) shows that anyway.

So, how does rails handle foreign key associations? I haven't seen anything built-in to migrations to do this. It seems like rails handles this in the model instead of the database. Certainly goes against traditional thinking... :dunno:

[Luke Redpath]

So, how does rails handle foreign key associations? I haven't seen anything built-in to migrations to do this. It seems like rails handles this in the model instead of the database. Certainly goes against traditional thinking... :dunno:

Rails is opinionated and cares little for "traditional thinking". I'm pretty sure you can set up foreign key constraints in migrations (you can certainly execute raw SQL in them) but unless your database HAS to be an integration point (and think carefully about that as there is often more domain logic than the kind of constraints databases naturally handle that needs enforcing - hence the need for a rich domain model), I suggest you forget about them and keep your constraints where they belong...in your domain model.

[kyko]

If your rails app is going to be the only thing using the DB, i would forget about foreign key constraints. Rails does not need them. Rails is a "Do not repeat yourself" type of framework so since you already define that type of stuff in the models there is no reason for the DB to have to know about it.

[CompiledMonkey]

Yeah, I mean, I can kind of understand that. However, it reallllly goes against database theory. What happens if someone goes into the database directly and edits something that conflicts with your model? I know, they shouldn't, but it happens and it happens often. I think it makes sense to do both but hey, I probably won't.

[pjleonhardt]

They shouldnt, and don't let them..
If they need to control the rows directly, have them go through the console, that way its still going through your models..

[Luke Redpath]

Yeah, I mean, I can kind of understand that. However, it reallllly goes against database theory. What happens if someone goes into the database directly and edits something that conflicts with your model? I know, they shouldn't, but it happens and it happens often. I think it makes sense to do both but hey, I probably won't.

Like I said, unless your working on an integration database (most web apps probably aren't) then there is no reason for anybody to do this EVER.

[vgarcia]

Yeah, I mean, I can kind of understand that. However, it reallllly goes against database theory. What happens if someone goes into the database directly and edits something that conflicts with your model? I know, they shouldn't, but it happens and it happens often. I think it makes sense to do both but hey, I probably won't.

If you have complex business rules governing your data then you shouldn't be allowing direct database editing unless it's through your business logic. But this sometimes falls into the magic realm of unicorns and happy puppies, so in that case add the FKs yourself.