I am working on an Incremental structure change vendor plugin. The goal is to be an addon to any schema. Deals with executing all the patterns for schema migration on live data. Will handle most of, if not all of the listed structure refactorings listed here: http://www.agiledata.org/essays/databaseRefactoringCatalog.html
I'm going to target mysql first, but hopefully I can migrate it to be db independant. The main concern that I need to deal with for my app is I don't have complete control over all the code which is accessing the models. So I cant just change the schema or it will break the other code which depends on it and is not on the same release cycle. So I need to do staggered incremental refactorings which will allow the developers of the other third party code at least one version where they can migrate from one version of the schema to another. Some of this can be done in the Controller for these external calls where they pass a version parameter and the controller/model deal with formatting the results. But when the third party has direct access to the DB (for Reporting etc) then the db will need to deal with synchronizing the fields via triggers etc. As an example of how this works. If I needed to rename a field from 'fielda' to 'fieldb' I can't just rename the field because the code that depends on fielda would then break. I would create a new field 'fieldb' and add a synchronize method either via storedproc or preferably in the model to keep fielda and fieldb in synch for one version with a deprecation note and date on fielda. The next release would then drop fielda and the synchronizing method. This allows all new code to deal with fieldb and retains backwards compatibility with code that is not in my control to still refer to fielda. To deal with data migration I will have two methods for each structure change that can be provided. PreChange code that runs before the schema is modified and PostChange code which runs after the schema is modified. This will enable you to provide custom sql/php to migrate and modify the data that already exist in the DB. The migration engine by default will be able to deal with quite a bit of these data changes. But there are always cases that don't fit a standard pattern. All changes will have a checkcode that can determine if the change needs to occur. This will be my second re-write of this type of system. Its unfortunate that the written code is in a completely different language, but its probably better to do some further thinking as I put this system together for the cakephp environment and do a clean coding based on the cakephp design concepts. The maintenance form for this plugin will allow you to view the list of schema changes and eventually have some nice wizards to deal with adding the various types of changes with appropriate deprecation info etc. The first release of this will only deal with updating the schema and migrating the data. Then I will follow that up with a release that will deal with the staggered synchronization. If anyone else is interested in helping with this effort, I believe this to be a valuable tool for any app which has many tables to maintain where the app is ever evolving. [EMAIL PROTECTED] On Nov 14, 3:56 am, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > Gwoo, migration step is not only change DB structure. > Migration step also represent rule how db changed from step to step, > with data modification. > If you need update some columns we use migration step for it. > I like schema snapshot idea but it is simplification of general case. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Cake PHP" 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 -~----------~----~----~----~------~----~------~--~---
