Re: MDB2_Schema XML Syntax Additions
| From: | Manuel Lemos | 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/