SitePoint Sponsor

User Tag List

Results 1 to 9 of 9
  1. #1
    SitePoint Guru CompiledMonkey's Avatar
    Join Date
    Sep 2002
    Location
    Richmond, VA
    Posts
    975
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    [Rails] Lets talk about migrations

    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?

  2. #2
    ☆★☆★ silver trophy vgarcia's Avatar
    Join Date
    Jan 2002
    Location
    in transition
    Posts
    21,235
    Mentioned
    1 Post(s)
    Tagged
    1 Thread(s)
    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.

  3. #3
    SitePoint Guru CompiledMonkey's Avatar
    Join Date
    Sep 2002
    Location
    Richmond, VA
    Posts
    975
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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:

  4. #4
    SitePoint Guru silver trophy Luke Redpath's Avatar
    Join Date
    Mar 2003
    Location
    London
    Posts
    794
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by CompiledMonkey
    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.

  5. #5
    SitePoint Enthusiast kyko's Avatar
    Join Date
    May 2006
    Posts
    32
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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.
    Stop Global  

  6. #6
    SitePoint Guru CompiledMonkey's Avatar
    Join Date
    Sep 2002
    Location
    Richmond, VA
    Posts
    975
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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.

  7. #7
    SitePoint Addict
    Join Date
    Jan 2006
    Posts
    268
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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..
    If you give someone a program,
    you will frustrate them for a day;
    if you teach them how to program,
    you will frustrate them for a lifetime.

  8. #8
    SitePoint Guru silver trophy Luke Redpath's Avatar
    Join Date
    Mar 2003
    Location
    London
    Posts
    794
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by 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.
    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.

  9. #9
    ☆★☆★ silver trophy vgarcia's Avatar
    Join Date
    Jan 2002
    Location
    in transition
    Posts
    21,235
    Mentioned
    1 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by 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.
    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.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •