I have to admit that a lot of the joy I get from using MongoDB is during dev.
While you still have to think about your schema, it does mean that you're not constantly writing and removing migrations (rails), while an application is still evolving.
In Symfony2 (php) migrations are created by comparing the new schema with the old one. Is that not the case for Rails? What do you mean 'constantly writing migrations'?
Rails does not specify the mapping of models to database schema, so it requires specification of migrations instead to document changes to the database that go along with any code changes. So migrations are explicit commands (in a pretty simple dsl) to add columns etc. spread out over many files as the application evolves. This means each schema change requires adding a migration file with those changes in it, rather than modifying a master schema or mapping. There is a schema.rb file but it is created/modified automatically.
There are trade-offs to each approach but it is probably one of the areas that Rails could still improve by looking at other ORMs - I'd prefer to see the schema specified along with constraints etc for each field at the top of each model to make it explicit and self-documenting, and perhaps doing away with migrations altogether.
Comments
I have to admit that a lot of the joy I get from using MongoDB is during dev.
While you still have to think about your schema, it does mean that you're not constantly writing and removing migrations (rails), while an application is still evolving.
In Symfony2 (php) migrations are created by comparing the new schema with the old one. Is that not the case for Rails? What do you mean 'constantly writing migrations'?
Rails does not specify the mapping of models to database schema, so it requires specification of migrations instead to document changes to the database that go along with any code changes. So migrations are explicit commands (in a pretty simple dsl) to add columns etc. spread out over many files as the application evolves. This means each schema change requires adding a migration file with those changes in it, rather than modifying a master schema or mapping. There is a schema.rb file but it is created/modified automatically.
There are trade-offs to each approach but it is probably one of the areas that Rails could still improve by looking at other ORMs - I'd prefer to see the schema specified along with constraints etc for each field at the top of each model to make it explicit and self-documenting, and perhaps doing away with migrations altogether.