> 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 -~----------~----~----~----~------~----~------~--~---
