5 ms·

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 in

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 database exists without the application. The application does not exist without the database. You might inherit a database/schema from someone else. And once your application grows, the database will surely have additional clients: you might want to access it via SQL directly or from some other language. > One thing I'm sure you'll agree with is that computers are good at grunt, non-creative work. It's been proven that you can reliably wrap each row in an object and each column's field with a getter/setter pair. It's easy. Totally non-creative, grunt work. That's what Active Record does. Migration generation via diffing schemas? That's a much harder, in fact provably intractable problem! There are many ways to get from A to B. 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.

moe 15y ago
For one, the database is the only place where the entire schema is maintained. That may be true for rails, but not for most other ORMs that don't follow the AR pattern. Said other ORMs take authority over the schema, which means by default they will sync the database to match your code - although the degree to which that is enforced is usually configurable. If I need to go add an index to a production system Then you will of course either test the change on a staging system first, or quickly backport the change after the hotfix. Whether the backport is done through a rails migration or a django model-change is not relevant to this discussion. You might inherit a database/schema from someone else Red herring. It's a rare case and people have managed this scenario with ORMs other than AR just fine since long before Rails was conceived. Migration generation via diffing schemas? That's a much harder, in fact provably intractable problem! A wide range of tools has a pretty good handle on this problem. (sqldelta.com, postfacto.org, xsql, red-gate.com, etc.) Ambiguous changes are pretty rare during the evolution of your average webapp schema. Machines can very well solve 99% of cases on their own, and smartly interrogate the user for the rest.
stretchwithme 15y ago
One nice thing about migrations describing your schema is that they can be used to migrate databases from different vendors. But if you rely upon scripts to create and migrate databases, you need to write a script for each one. And there is no partial rollback. You get to write another script for that or do it manually. In olden times, I used to have to write these for Oracle and SQL Server, and just keeping them in sync was a challenge. And you had to write a specific script or execute multiple smaller scripts to move from version 1.3 of the schema to version 3.9. The incremental, db agnostic, reversible approach is much better. But you really need to make sure the end result is exactly what you expect before executing on production (and back it up first of course). The db-specific script seems much easier to trust, with no magic happening, especially when its atomic.
prodigal_erik 15y ago
> More importantly, the database exists without the application. This. I'm continually amazed how many people think they will only ever have one application talking to their database. Unless your project promptly crashes and burns, you're going to find yourself using tools in different languages, and it's going to be incredibly painful not to have invested in competent data modelling that avoids relying on some specific ORM.
- moe 15y ago
  I repeat: Red Herring. Competent data modeling and AR migrations are in no way related. Moreover most grown up applications consist of multiple database, since it would be unwise to mix e.g. reporting concerns into a webapp database schema.
masklinn 15y ago
> For one, the database is the only place where the entire schema is maintained. This includes indexes, constraints, relationships, etc. 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.

moe 15y ago

For one, the database is the only place where the entire schema is maintained. That may be true for rails, but not for most other ORMs that don't follow the AR pattern. Said other ORMs take authority over the schema, which means by default they will sync the database to match your code - although the degree to which that is enforced is usually configurable. If I need to go add an index to a production system Then you will of course either test the change on a staging system first, or quickly backport the change after the hotfix. Whether the backport is done through a rails migration or a django model-change is not relevant to this discussion. You might inherit a database/schema from someone else Red herring. It's a rare case and people have managed this scenario with ORMs other than AR just fine since long before Rails was conceived. Migration generation via diffing schemas? That's a much harder, in fact provably intractable problem! A wide range of tools has a pretty good handle on this problem. (sqldelta.com, postfacto.org, xsql, red-gate.com, etc.) Ambiguous changes are pretty rare during the evolution of your average webapp schema. Machines can very well solve 99% of cases on their own, and smartly interrogate the user for the rest.

stretchwithme 15y ago

One nice thing about migrations describing your schema is that they can be used to migrate databases from different vendors. But if you rely upon scripts to create and migrate databases, you need to write a script for each one. And there is no partial rollback. You get to write another script for that or do it manually. In olden times, I used to have to write these for Oracle and SQL Server, and just keeping them in sync was a challenge. And you had to write a specific script or execute multiple smaller scripts to move from version 1.3 of the schema to version 3.9. The incremental, db agnostic, reversible approach is much better. But you really need to make sure the end result is exactly what you expect before executing on production (and back it up first of course). The db-specific script seems much easier to trust, with no magic happening, especially when its atomic.

prodigal_erik 15y ago

> More importantly, the database exists without the application. This. I'm continually amazed how many people think they will only ever have one application talking to their database. Unless your project promptly crashes and burns, you're going to find yourself using tools in different languages, and it's going to be incredibly painful not to have invested in competent data modelling that avoids relying on some specific ORM.

moe 15y ago
I repeat: Red Herring. Competent data modeling and AR migrations are in no way related. Moreover most grown up applications consist of multiple database, since it would be unwise to mix e.g. reporting concerns into a webapp database schema.

masklinn 15y ago

> For one, the database is the only place where the entire schema is maintained. This includes indexes, constraints, relationships, etc. 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.