Dardo can you elaborate on why schemas are better than migrations in iterative development?
Just to address some issues here: 1. Migrations as "Patches" - Migrations CAN be patches. Migrations are not patches though. For example, in Joel's system you can most certainly create a migration supporting a model that is complete. In many cases models won't need tweaks, but in some cases, particularly in multi-developer environments, having the ability to create patches is critical. 2. Migrations are incomplete - Migrations CAN be incomplete, but when migrations are run in sequence they are as complete as a Schema. Git allows you to keep a local copy of the SCM in which you can create your own revisions and then sync it later. Many developers, in fact I would suggest most, do not use Git yet. I would argue that the majority of folks are on some flavor of SVN or CVS. In these cases there is no local revision only the revision you have to commit. Let me propose the counter-argument to why migrations are superior to Schema. I think this is a debate that could be endless, but in terms of commonly accepted practice in interative agile development there are many more proponents of the migration model than the Schema model. 1. Migrations are iterative. When you're developing it is useful to back out model changes if they do not work. With Schema, you're working directly with the SQL which is not necessarily database agnostic. Once you back out that change you have no way to return to any other state unless you check out a file from your SCM. In this way your iterative development model is supported step-by-step with your migrations. You can track and move your application to any state you need without needing to check out full blown schemas. 2. Migrations are multi-developer friendly. Migrations are iterative, so one developer's work will not overwrite another developer's work. In the Schema model you've got multiple developers committing their latest schema and relying on the SCM to stitch the changes into the proper order. Migrations also quickly allow developers to review specific database changes without needing to review a single large file and finding the changes. 3. Migrations allow easier rollout Let's say you need to roll out a single feature. In a migration you just rollout that migration on your production environment with your code deploy and you're set. In a Schema environemnt you need to backup your database, rollout the new schema, restore the data and you're good to go. While database backups should be a part of any production environment rollout, having to backup / restore for even minor database changes can be tiresome particularly when you're just trying to fix a single bug in a production application. 4. Migrations have a reputable body or work behind them: http://www.oracle.com/technology/pub/articles/kern-rails-migrations.html http://www.oreillynet.com/pub/a/ruby/2007/05/17/cookin-with-ruby-on-rails---may.html http://www.ibm.com/developerworks/web/library/j-cb08156.html While I think there are many ways to handle database schemas, the migration model is currently the best of breed model on the market. If multi-developer iterative design is the new model for application development then there is no reason to avoid migrations. Joel's work has been ongoing and his latest efforts are most definitely worth a look. His migration model should make it into Cake 2.0 if not sooner because of the value it adds to the core set of console tools available with cakePHP. Thank you to Dardo for posting his commentary about Schema because it got me thinking about why I prefer migrations. Hopefully between his well thought out argument and my counter-point cakePHP developers will have a background to make a choice on what will work best for them. On May 18, 11:02 am, "Dardo Sordi Bogado" <[EMAIL PROTECTED]> wrote: > > Hmmmm... some day I just might hack the schema shell to be truly migrations > > I hope you don't, they are just great the way there are. > > The cake Schemas are far better than migrations, because they are a > different concept. > > First we should get the concept behind cake's Schemas and how they > are different from Rail's migrations. > > The Schema (capitalized refers to cake's Schema) is a way to describe > the current state of the database, whether a migration is a way to define > a change to it's state. > > Think of Schemas as snapshots of the db and migrations as a patch. > > Schemas in cake works like git (the scm I use), recording the full state > every time, instead of just a delta (like svn does), this brings a lot > of flexibility and power allowing for example: > > * To let the SCM do the hard work of schema version control, merging, etc. > * To have a unique place where to find the current database structure > that the application needs to run. > * Using any tool of your choice for doing the changes to the database. > > Having this in mind, we can say that Schemas are a way to keep with the > application code a description of the database structure. > > Think you get a fresh checkout of the app to work with, next thing > you need is the database for the application. > > Here is where cake schema shell really shines. It lets you synchronize > in both ways the Schema and the database. > > Last thing to keep in mind is the difference in the workflows: > > Migrations: > ----------- > > 1. Create a migration in the stupid language that they work (no matter > what it is, you always end hating it). > 2. Run the migration to update the DB. > 3. Go and hack your code (test it also if you feel like doing so). > 4. Then commit to the SCM. > 5. Other developers checkout your changes and run migrations. > > Now, if you are in a truly parallel development scenario this doesn't > works well. > Other developers have introduced changes in the schema and now you > have to realize > what migrations and in what order you must run to get it working. > > Schemas: > -------- > > 1. Do the changes to the DB with your tool of choice. > 2. Go and hack your code (test it also if you feel like doing so). > 3. Update the Schema (using cake schema shell) > 4. Then commit to the SCM (code an schema). > 5. Other developers update and merge (mostly gets done by the SCM) the > changes to code an schema. > 6. Then they just synchronize their DB using the schema shell. > > Every one on sync and happy! > > Cake Schema is superior in various technical aspects to migrations, > but the key difference is in their filosofy. > > Regards, > - Dardo Sordi. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "CakePHP" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cake-php?hl=en -~----------~----~----~----~------~----~------~--~---
