Re: DBM Compatibility layer

Hello, Brent Cook wrote:

Oh, and I forgot. A generic query manager probably also needs a generic method of defining the "data definition" queries as referenced in DB. I find that MDB uses an XML schema to define schemas very attractive. I would like to critique it now (though I'm by no means an XML language lawyer ;)

I was the one would developed Metabase from which Lukas derived MDB. So, I can advance you that there is an explanation for everything be the way it is.

First, it is my understanding (from reading through "XML Unleashed!" anyway) that <tag></tag> type tags are generally used when an element might exist any number times. Given that, is it not required that a table

That seems to be a personal criteria of the editor because it is not by all means a general rule applied a significant part of XML developers.

have a name and a field have a name and type? Also, a table, field or database cannot have more than one name, or so I assume. Reformatting to these assumptions, we get:

If you read in the Metabase documentation that is explained that this is the SML (Simplified XML) syntax. In that syntax, XML tags do not have attributes nor there are any XML processing instructions. This simplifies XML parsing a lot but the most important reason for this is that for XML be really extensible, which is what the X in XML means, you should be able to extend the composition of the data values eventually using more tags. If you put data values in tag attributes, you can't extend those values because you can't insert tags within attributes values like you can within tags. See the explanation on the <variable> tag in the other reply for understanding better the importance of this.

<database name="test"> <create><variable>create</variable></create> <table name="users"> <declaration> <field name="user_id" type="integer" default="0" notnull="1"/> <field name="user_name" type="text"/> <index name="users_id_index" field="user_id" unique="1"/> </declaration> </table> Maybe this is 6==0.5*dozen but it seems to make the defining the trivial case for a schema a lot less verbose but just as informative.

This was what Metabase XML schemas looked initial before I realized the need to extend the values of some tags with non-hardcoded values. Fortunately nobody besides me used that version of Metabase schemas because I deliberately waited 1 year before I decided that all the design aspects of Metabase were stable so I would not need to make any backwards incompatible changes like this of moving values from tag attributes to nested tags. I am glad I waited that long because I did not have to compromise peoples applications with the spaguetti code that results for making drastic design changes in software that is already public. I don't believe in releasing Open Source software too soon precisely to not deal with the need of making design changes too soon. If you go and analyze some code of Open Source projects you see a lot of ugly of design patches because of this problem. This is just a personal style of development. Metabase just took a year before I decided it was ready. I have another even more ambitious project that I have been holding for over 3 years now, precisely for the same reasons, despite I already made a couple of public presentations to sense the level of acceptance of the public. This is just a side note to explain that if somebody, not necessarily me, is working on something for a long time, there are certainly good reasons for some things be the way they are and if you disagree with those things, chances are that you may have not thought of all the details that motivate the current design. So, keep an open spirit.

Second: What is the <create></create> section for? I didn't touch it because I haven't seen this before.

This is a flag to tell the Metabase schema manager class to not try to create the database being defined, just the tables, fields, indexes, sequences. This is necessary either because the Metabase driver has no way to create the database, possibly because it is a very database specific procedure that can't be done from PHP, or because you have split your schema in many separate definitions and only the installation of the first schema definition is supposed to lead to new database creation since the database will already exist when you install the rest of the definitions. This is a very common need when you want to install a modular application that has a own schema space for each module.

Third: I have no experience with non-relational databases. Could this XML format extend to cover heirarchical data such as that used in LDAP? What about an object relational database? Would you need something more like this?

Never thought of that because it was outside the scope of the project. If you see that this type of XML schema does not suite for hierarchichal databases, I suggest that you design a new one. I don't think it is right use a hammer to insert a screw.

<schema> <object name="person"> <field name="last_name" type="text"/> <field name="first_name" type="test"/> </object> <category name="University"> <category name="Student"/> <category name="Faculty"/> </category> </schema> It would be helpful if someone who has already thought about this sort of thing could help me continue thinking about it.

There are mappings of hiararchical information design in to relational, but I don't think that is what you need. Regards, Manuel Lemos