5 ms·

Just to be contrary: > 1) The database holds the authoritative schema. You shouldn't duplicate it in your code. I care about the authoritative data model, whi

by awj 15y ago

Just to be contrary: > 1) The database holds the authoritative schema. You shouldn't duplicate it in your code. I care about the authoritative data model, which is slightly different from the authoritative schema. Beyond that, I don't edit the database schema. There are many cases where I'm happier to have a complete data model in one location versus (at least) two and needing to mentally parse how rails reacts to the database schema. > 2) What if you want to do something more complicated, like split the values in one column into two columns? You're going to need support for manual migrations anyway. In case you didn't notice, the automatic migration was happening through a --auto command line flag. Manual migrations exist, and are the default. > 3) Including column declarations in your model forces the database's strong typing system onto what should be plain old Ruby/Python objects. The result is ineffective domain objects. Why should these be plain old Ruby/Python objects? ActiveRecord already is a pretty extensive DSL for relating objects to database tables. Does including attribute descriptions really make it "not a plain old Ruby object" when we already have well developed support for field validation and relationship declarations? That said, I don't think the auto migrations are good idea. You're right, eventually you'll want to do a manual migration. At that point it's painfully easy to create a situation where your manual migration depends on properties of your model that have since changed. It's a problem akin to using your AR classes to help manipulate data in a migration. We have a point in our migration history we simply cannot restart from because it uses a model class that has since been removed.

moe 15y ago
At that point it's painfully easy to create a situation where your manual migration depends on properties of your model that have since changed. I don't understand the situation you're describing. The migration-files, once created, are independent from the model. That means you can re-run the chain at any point in time, regardless of what your current model looks like. Having an auto-generator for the migration files doesn't change that.
- snprbob86 15y ago
  He's making the same mistake I once made: Trying to use his models from the migrations. I'd really like to see Rails raise a deprecation warning if a model gets dynamically loaded by a migration....
  - jarin 15y ago
    Every Rails developer makes that mistake once (well, hopefully not more than once). What I'd really like to see next is a way to version seeds.rb.
    - foca 15y ago
      git?
      - jarin 15y ago
        seeds.rb isn't intended to be run more than once on a particular database instance. Running it more than once results in duplicate entries, unless you're explicitly checking for dupes (not always possible). It looks like seedbank is fairly close to what I want though, as it lets you maintain multiple sets of seeds: https://github.com/james2m/seedbank https://github.com/james2m/seedbank
    - james2m 15y ago
      @Jarin I've been thinking about versioning seeds or at least being able to alter / update in place seeds. Did you have any thoughts on how you would like the versioning to work?
snprbob86 15y ago
> I care about the authoritative data model Me too, but the truth about the world is that all inherit complexity is accompanied by incidental complexity :-/ You've got a database, you need to respect it's existence. > mentally parse how rails reacts to the database schema It's hilariously straightforward in 99% of cases: For each column, a getter and setter are created. The getter directly calls read_attribute and the setter calls write_attribute. Those two methods do standard string/integer/date/etc primitive conversion. What's there to map in your head? > Manual migrations exist, and are the default. Right, that's the point I'm making. They should be the default. I'm also saying that I shouldn't have to write a migration AND maintain some declarations in the python file. > it's painfully easy to create a situation where your manual migration depends on properties of your model that have since changed. Oh, I've made this mistake. Since then, I stopped referencing my models in my migrations. I just run raw SQL (or the shorthand Ruby functions for the most common cases). As a result, my migrations are waaaay faster (batch updates rather loops, etc) and I've never had this problem since.
- awj 15y ago
  FYI, you can re-declare as much of the model class as you need and simply call reset_column_info as a class method before using it. The models at work have some homemade serialized attributes (don't ask), and this makes it easier to deal with that situation.

by awj 15y ago

moe 15y ago

At that point it's painfully easy to create a situation where your manual migration depends on properties of your model that have since changed. I don't understand the situation you're describing. The migration-files, once created, are independent from the model. That means you can re-run the chain at any point in time, regardless of what your current model looks like. Having an auto-generator for the migration files doesn't change that.

snprbob86 15y ago
He's making the same mistake I once made: Trying to use his models from the migrations. I'd really like to see Rails raise a deprecation warning if a model gets dynamically loaded by a migration....
- jarin 15y ago
  Every Rails developer makes that mistake once (well, hopefully not more than once). What I'd really like to see next is a way to version seeds.rb.
  - foca 15y ago
    git?
    - jarin 15y ago
      seeds.rb isn't intended to be run more than once on a particular database instance. Running it more than once results in duplicate entries, unless you're explicitly checking for dupes (not always possible). It looks like seedbank is fairly close to what I want though, as it lets you maintain multiple sets of seeds: https://github.com/james2m/seedbank https://github.com/james2m/seedbank
  - james2m 15y ago
    @Jarin I've been thinking about versioning seeds or at least being able to alter / update in place seeds. Did you have any thoughts on how you would like the versioning to work?

snprbob86 15y ago

> I care about the authoritative data model Me too, but the truth about the world is that all inherit complexity is accompanied by incidental complexity :-/ You've got a database, you need to respect it's existence. > mentally parse how rails reacts to the database schema It's hilariously straightforward in 99% of cases: For each column, a getter and setter are created. The getter directly calls read_attribute and the setter calls write_attribute. Those two methods do standard string/integer/date/etc primitive conversion. What's there to map in your head? > Manual migrations exist, and are the default. Right, that's the point I'm making. They should be the default. I'm also saying that I shouldn't have to write a migration AND maintain some declarations in the python file. > it's painfully easy to create a situation where your manual migration depends on properties of your model that have since changed. Oh, I've made this mistake. Since then, I stopped referencing my models in my migrations. I just run raw SQL (or the shorthand Ruby functions for the most common cases). As a result, my migrations are waaaay faster (batch updates rather loops, etc) and I've never had this problem since.

awj 15y ago
FYI, you can re-declare as much of the model class as you need and simply call reset_column_info as a class method before using it. The models at work have some homemade serialized attributes (don't ask), and this makes it easier to deal with that situation.