Re: MDB2_Schema XML Syntax Additions

From: Date: Fri, 14 Jul 2006 07:42:26 +0000
Subject: Re: MDB2_Schema XML Syntax Additions
Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-43474@lists.php.net to get a copy of this message
Hello, > The new XML syntax for MDB2_Schema is defined here: > http://oss.backendmedia.com/MDB2/MDB2_Schema > > This approach brings to MDB2_Schema the ability to handle UPDATEs and > DELETEs. > > This is not the final version as there are some elements not finished > yet (<function> is one of them). > By the other hand we have not yet addressed in the current syntax the > ability to control the order in which DDL changes and DML commands are > issued (like do this update before doing DDL on this table, or do this > update after doing the DDL on this table). Since Lukas brought my attention to this, I took a look to see what is being planned. Regarding defining update and delete actions in the initialization sections, I am afraid these do not make much sense there. The initialization sections are meant to define actions to execute when the schema is installed for the first time only. Since when the tables when they are created, update and delete actions would not do anything, as there would be no rows to update or delete. I suppose you meant supporting update and delete actions for migration updates. That would make sense. In that case, I suggest that you define a migration section distinct from the initialization section. There you could have update, delete and even new insert actions. Adding support to migration actions could be a good thing. I have thought about that some time ago, but I am afraid there are some challenges to design and implement migrations. One of the greatest things about defining schemas as static XML files, is that you can perform changes between arbitrary revisions of a schema just by having the currently installed and the new schema definition file. You do not need any intermediary revisions that the schema may have gone through. Performing arbitrary revision migrations like this is not always possible. You may not be able to skip intermediary steps. I do not have yet a good solution for all problematic migration cases. This is something that needs careful thought before somebody rushes to first idea that comes to mind, and later realize that it was not a good idea at all. -- Regards, Manuel Lemos Metastorage - Data object relational mapping layer generator http://www.metastorage.net/ PHP Classes - Free ready to use OOP components written in PHP http://www.phpclasses.org/

« previous php.pear.dev (#43474) next »