Re: MDB2_Schema XML Syntax Additions

Manuel Lemos wrote:

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.

Yes, probably makes sense.

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.

Yup, this is a topic I pushed off for now (its that Igor listed under the question of controlling the order of DDL/DML) and that I discussed in a recent talk at php|tek: I guess if we introduce a <migration> tag we need to add in some control statements that can handle deciding under what conditions and in what order the defined DML should be executed, relative to any DDL that needs to be executed. For extremely complex situations however I would suggest people to simply keep the <migration> DML in a separate file. MDB2_Schema supports reading the structure from one file and using the <initialization> tag information from another file. Similarily people could script the update steps by comparing an md5 checksum of the schema file, or things like that. I always keep my <initialization> tags separate from the structure information. However the main reason why I keep them in XML instead of writing an MDB2 based script is that I can quickly dump out <initialization> XML files, but I will not be able to quickly dump out <migration> XML files. So I agree, its important that the XML format provides some additional value. Aside from the value of keeping all schema related in one format (namely XML), it should also be the ability to hook into the DDL altering that is done when two schema files are compared. Thank you for the feedback Manuel! regards, Lukas