Re: DB_DataObject and MDB

Matt, I've cc'd into pear-dev, as Justin Patrin, is also very interested.

I was able to get a two very basic versions of MDB_DataObject working. (can you check in the code you have done so far to pear cvs : call it MDB.php under the dataobjects folder. or just put it in a subfolder of pear/DB_DataObjects/DataObjects called MDB for the time being..)

One version just uses MDB's pear_db wrapper class, and the other version I just replaced all DB specific calls with MDB calls.

I suggest in the short term, it is called DB_DataObject_MDB, and extends DB_DataObject it should help as a) there are quite a few 'non-specific methods' that may not need touching. b) it's alot easier to see what the major differences are.. Eventually we can depreciate DB_DataObjects, and remove the inheritance. (perhaps even reversing the A extends B) and rename it to [M]DB[2]_DataObjects[2] or something....

We would however like to make MDB_DataObject more tailored to MDB to make use of it's more relevant features such as type abstraction I'd be very carefull with this, the ability to actually move code from one database to another is less important that a single API for all databases (less to learn). some of the datatype abstraction in MDB

(last time I looked) was very damaging, and counter intuative. and schema reverse/forward engineering. This may be usefull as a source for the generator.. I can see the various usage patterns: a) MDBXML schema as the core datastorage design medium. - point the generator at it. - generates classes and structure (see notes below about this) b) Database as the core design medium. - point generator at DB - generates MDBXML

    - in turn generates classes and structure.

c) On the fly usage.. ( Database as the core design medium. ) - point dataobjects at database - structure is read on the fly, and schemas are generated (MDBXML part is skipped totally.) Schema: Marcus brought up the problem, that on a large database, the current big ini structure is problematic (eg. slow). - The solution to this is to add a schema definition to the bottom of each class file. eg. $GLOBALS['_DB_DATAOBJECT']['projectname']['table'] = array( 'id' => DB_DATAOBJECT_INT, 'name' => DB_DATAOBJECT_STR & DB_DATAOBJECT_NOTNULL, ... ); I think jumping to using MDBXML directly for datatype querying may cause far too many problems (Eg. introduces alot of bugs, that may take quite a while to iron out.) - the current datatype system is well worked out and tested, and alot of bugs have been squashed over the years..

In the mean time, I was wondering if we could converse in more detail regarding your future plans for DB_DataObject.

There is a todo list in cvs.. I did update it recently, but cant remember everything of the top of my head.. Also, I'd like to

discuss some ideas I have had and also some questions regarding DB_DataObject's code.

May be worth keeping as much as possible on pear-dev, it makes a good record if we forget something.. ;) - but dont forget I'm GMT+8, and arround most of the day here, keeping it on #pear is probably a good idea as well. Regards Alan

Matt Scifo

-- Can you help out? Need Consulting Services or Know of a Job? http://www.akbkhome.com