xPDO schema builder

Hi !

Toying with xPDO, I found it easier for me to have a tool to built my schema and model.

So I made myself the Schemabuilder tool, and I thought others might find it helpfull.

The basic idea is that you can create or delete objects, and in each object, create elements (fields) or relationships, and remove them. You can save your file as xml, load an already existing xml file, and even build your model.

Try it if you want, and feel free to improve/correct it as well !

Note : destination file will always be saved in a "schema" subfolder, and ’.xml’ will be added automatically.
Built model will be placed in a "model" subfolder.

Don’t forget to edit the parameters in schemabuilder.php to adapt this to your database and xPDO path.


A question thought :
While loading the ModX schema, I noticed some attributes I don’t understand :
The following fields datas :
- generated="native"
- indexgrp="foci"
- indexgrp="content_ft_idx"
What are these for ? How do they translate in mysql terminology ?

Some relationships (aggregate) have a key="id" attribute, but I don’t find any reference to it in http://svn.modxcms.com/docs/display/xPDO20/Defining+Relationships, could someone explain to me what it is for ?

Best regards

First, very cool Thalion.

But I want to warn you that this schema is changing as we speak. I’m working on support for sqlite and am improving some of the schema right now, especially related to indexes. I will try and work on the schema definition soon.

In the meantime...
Quote from: Thalion at May 02, 2010, 10:23 AM

While loading the ModX schema, I noticed some attributes I don’t understand :
The following fields datas :
- generated="native"
- indexgrp="foci"
- indexgrp="content_ft_idx"
What are these for ? How do they translate in mysql terminology ?
Quote from: Thalion at May 02, 2010, 10:23 AM

generated="native" indicates that the field is a primary key generated by the database engine itself, thus "native". It equates to AUTO_INCREMENT in MySQL terminology.

Some relationships (aggregate) have a key="id" attribute, but I don’t find any reference to it in http://svn.modxcms.com/docs/display/xPDO20/Defining+Relationships, could someone explain to me what it is for ?

key="id" was an old attribute in the original xPDO schema format that is no longer used. It was replaced by alias and is ignored currently.

However, keep in mind that any custom attributes you add to the schema elements will be added to the related generated map entries.

Quote from: OpenGeek at May 03, 2010, 07:26 AM

First, very cool Thalion.

But I want to warn you that this schema is changing as we speak. I’m working on support for sqlite and am improving some of the schema right now, especially related to indexes. I will try and work on the schema definition soon.

Hey Jason --

Once you are done, the schema def file will be very handy for validating against...

..also another related question to changing xpdo schemas:

Once you have ’semi-finalized’* the refactored xPDO base classes to accommodate both sqlite and mysql to your liking, do you think it would reasonably doable for modx programmers to add additional providers for xpdo? I have a couple of current clients with many, many-- too many, MS Access custom databases, and I wouldn’t mind taking a shot at possibly writing a xPDO driver/provider for them. (I know ms access DBs can’t be too high on the xpdo/modx/php/open source users list of priorities )

When they are ready, Im assuming I can paw though the files in both /core/xpdo/om/mysql, & /core/xpdo/om/sqlite; basically create a new folder for Access, and mimic the classes, function calls, signatures, etc and be in the ball park.

Any thoughts on that kind of schema/driver/provider extensibility?


*Is any API ever actually finalized?

Quote from: wowzow at May 04, 2010, 09:39 AM

*Is any API every actually finalized?

Well I think that’s essentially the question that the Large Hadron Collider was built to answer

Quote from: netProphET at May 04, 2010, 10:00 AM

Quote from: wowzow at May 04, 2010, 09:39 AM

*Is any API every actually finalized?

Well I think that’s essentially the question that the Large Hadron Collider was built to answer

Does Higgs Boson really solve the final API for the universe? What about alien life forms?
I know LHC, as big and powerful as it is, doesn’t help me much with an Access DB provider for xPDO though.

Since PDO supports connections to Access databases, I don’t see why you couldn’t write a driver for it.
However if I’m wrong, it’ll be interesting to know why.

Quote from: wowzow at May 04, 2010, 09:39 AM

Once you have ’semi-finalized’* the refactored xPDO base classes to accommodate both sqlite and mysql to your liking, do you think it would reasonably doable for modx programmers to add additional providers for xpdo? I have a couple of current clients with many, many-- too many, MS Access custom databases, and I wouldn’t mind taking a shot at possibly writing a xPDO driver/provider for them. (I know ms access DBs can’t be too high on the xpdo/modx/php/open source users list of priorities )

When they are ready, Im assuming I can paw though the files in both /core/xpdo/om/mysql, & /core/xpdo/om/sqlite; basically create a new folder for Access, and mimic the classes, function calls, signatures, etc and be in the ball park.

Any thoughts on that kind of schema/driver/provider extensibility?

That’s the whole point of xPDO, is to be able to port both the core O/RM model and your custom domain models easily to other PDO drivers, and allow you to optimize them for each platform. So yes, that would be the basic intention.

However, there is no Microsoft Access driver for PHP’s PDO. You would most likely have to use the ODBC driver, so you would be creating an odbc/ subdirectory and would be limited to ODBC rules for accessing it.

Quote from: netProphET at May 04, 2010, 10:57 AM

Since PDO supports connections to Access databases, I don’t see why you couldn’t write a driver for it.
However if I’m wrong, it’ll be interesting to know why.

Quote from: OpenGeek at May 04, 2010, 11:16 AM

However, there is no Microsoft Access driver for PHP’s PDO. You would most likely have to use the ODBC driver, so you would be creating an odbc/ subdirectory and would be limited to ODBC rules for accessing it.

ODBC stuff kinda gives me the heebie jeebies, to be honest. If the pdo driver was anything other than through odbc, I don’t think I would mind working with it. There are quite a few bugs kicking around in odbc, AFAI(used to)K.

Ive always accessed MS Access via Oledb in windows programming (remember Im still a green php/pdo newb). Anytime I tried odbc to connect to Access, there were bugs or limitations. So once oledb providers were available, I never looked back to odbc.

I’d probably, give this pdo provider a shot first, before odbc: PDO_OLEDB (dll here: http://sourceforge.net/projects/wapache/files/pdo_oledb/ dox here: http://wapache.sourceforge.net/oledb.htm)

(I assuming no one here has any experience (or even heard of) with this particular pdo_oledb driver. I haven’t done anything with it myself other than download it a month ago planning to try it to connect to Access with it.)

Quote from: wowzow at May 04, 2010, 02:07 PM

I’d probably, give this pdo provider a shot first, before odbc: PDO_OLEDB (dll here: http://sourceforge.net/projects/wapache/files/pdo_oledb/ dox here: http://wapache.sourceforge.net/oledb.htm)

(I assuming no one here has any experience (or even heard of) with this particular pdo_oledb driver. I haven’t done anything with it myself other than download it a month ago planning to try it to connect to Access with it.)

You assume correctly, I’ve never heard of it, but great to know that there is driver out there for it.