extending the mdb schema format
| From: | Lukas Smith | Date: | Thu, 21 Apr 2005 14:43:09 +0000 |
| Subject: | extending the mdb schema format | ||
| Groups: | php.pear.dev | ||
| Request: | Send a blank email to pear-dev+get-37319@lists.php.net to get a copy of this message | ||
Hi,
I know your are very busy Manuel and I want us to remain compatible. However I really need support for auto_increment in MDB2. I also wouldnt mind getting primary and foreign key support.
Since I know that interest in the format has increased considerably since I have unbundled and fixed many bugs in MDB2_Schema I want to bring this up on this list to give other people the opportunity to pipe in with their thoughts.
For reference see these documents:
http://backendmedia.com/MDB2/docs/xml_schema_documentation.html
http://backendmedia.com/MDB2/docs/MDB.dtd
http://backendmedia.com/MDB2/docs/MDB.xsl
http://cvs.php.net/co.php/pear/LiveUser/sql/auth_mdb_schema.xml
1) auto increment
Currently you can only define sequences as follows:
<sequence>
<name>foo</name>
<start>23</start>
<on>
<table>foo</table>
<field>bar</field>
</on>
</sequence>
The <start> and <on> tags are optional. The <on> tag basically lets you sync the sequence against a certain field in a table. Now I was pondering extending the <on> tag to also allow for an optional "<autoincrement>1</autoincrement>". This format is in the sprit of the rest of the tags in that it doesnt use atributes.
Now the problem is that we may need a separate syntax for "I only want autoincrement!" and "Use autoincrement if available." as MDB2 supports a nice mode where either auto increment or sequences are used. I dont really like something like "<autoincrement>force</autoincrement>" for this case.
I could also add something like this
<autoincrement>
<table>foo</table>
<field>bar</field>
<start>23</start>
<force>1</force>
</autoincrement>
This is also not very nice and seriously screws with how the current code works and the current DTD is structured.
2) Primary key
Currently the format only supports unique fields as follows:
<index>
<name>auth_user_id</name>
<unique>true</unique>
<field>
<name>auth_user_id</name>
</field>
</index>
Adding primary key support seems to be straightforward. Unique will remain the fallback and therefore it still makes sense to specify a name optionally eventhough it will usually end up being ignored or set to the first column in the contraint automatically by the RDBMS (like in MySQL):
<index>
<name>auth_user_id</name>
<primary>true</primary>
<field>
<name>auth_user_id</name>
</field>
</index>
3) Foreign key
This is the one I least thought about and that I have the least experience with. Obviously the number of <field> tags would need to match the number of <field> tags in the <on> tag. The <on*> tags can take either "cascade" or "restrict" as values. The <setaction> could accept "NULL", "DEFAULT" or "NO".
I dont really like the <on*> or <setaction> tags.
Maybe something like <setnull>1</setnull> would be better.
<index>
<name>auth_user_id</name>
<foreign>
<on>
<table>foo</table>
<field>
<name>bar</name></field> </on> <onupdate>cascade</onupdate> <ondelete>restrict</ondelete> <setaction>NULL</setaction> </foreign> <field> <name>auth_user_id</name> </field> </index> References: http://dev.mysql.com/doc/mysql/en/innodb-foreign-key-constraints.html http://www.postgresql.org/docs/8.0/interactive/ddl-constraints.html#DDL-CONSTRAINTS-FK regards, Lukas