31–35 of 35 posts
Wake me up when they finally generate those stupid migrations automatically (see http://south.aeracode.org/docs/tutorial/part1.html#changing-... ).
http://datamapper.org/ https://github.com/datamapper/dm-rails
Datamapper was one of the great parts of the Merb framework, and with rails 3 you can use it in place of Activerecord.
Earlier quoted context omitted.
When a migration runs, the schema.rb file is regenerated. This way, each checkin contains a complete snapshot of the schema that goes with that code. (side note: I think that schema.sql should be the default, not schema.rb)
Yes, that's what everybody refers to when they quickly need to look up a field. However, having to look in two places to understand your model is a bit cumbersome, isn't it? Especially when complex associations come into play and you have to resolve the rails identifier magic in your head... And then there's the question of why you should have to refer to a cached copy of your schema when you could just spell it all…
Earlier quoted context omitted.
> The database holds the authoritative schema. Why? > You shouldn't duplicate it in your code. If the database does not hold the authoritative schema, you're not duplicating anything. > 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. Of course, but it's not like the generated migrations are special. The…
For one, the database is the only place where the entire schema is maintained. This includes indexes, constraints, relationships, etc. If I need to go add an index to a production system, that is not captured in the code. I should, however, dump the schema to a .sql file and check that in, but that's still separate from the model's .py file, so that file can't be considered authoritative. More importantly, the databa…
not at all.
> If I need to go add an index to a production system, that is not captured in the code.
Depends of the ORM. With non-AR ORMs your index is very much captured in the code, as is the rest of the schema.
> More importantly, the database exists without the application.
1. That is not the case of the vast majority of databases and applications out there, which have a 1:1 coupling
2. Using an ORM does not preclude (or prevent) correct designs.
> The application does not exist without the database.
The application can very well be database-independent and run on 5 different (and incompatible) databases. If the sql schema is the canonical truth, you need 5 different schema files to handle all possible deployments of your application. If the ORM types definition is the canonical truth, one is enough and the ORM takes care of the details for each database.
> And once your application grows, the database will surely have additional clients
Baseless assertion.
> It's been proven that you can reliably wrap each row in an object and each column's field with a getter/setter pair.
So?
> Migration generation via diffing schemas? That's a much harder, in fact provably intractable problem!
Generating all migrations is intractable, generating 95% of migrations is not. Or South would not be able to do it.
> There are many ways to get from A to B.
So what?
> If you're going to leave it to a computer to generate either migrations or classes with getters and setters, I'd much prefer the computer do the getters/setters.
And I'd rather ask more of my tools. Different strokes for different folks.
Earlier quoted context omitted.
Yes, that's what everybody refers to when they quickly need to look up a field. However, having to look in two places to understand your model is a bit cumbersome, isn't it? Especially when complex associations come into play and you have to resolve the rails identifier magic in your head... And then there's the question of why you should have to refer to a cached copy of your schema when you could just spell it all…
If remembering attribute names is your concern, you can use an IDE or vim plugin for autocomplete, or just use annotated_models to add/update the schema down at the bottom of your model files on every db:migrate: https://github.com/openteam/annotated_models
My general point is that AR makes no sense for web applications.
Earlier quoted context omitted.
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....
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.