Re: DB_DataObject and MDB

Hi guys, I'm glad to see the power of MDB being brought to DB_DataObject -- or at least this integration being considered. I'm a big fan of MDB for PHP4 solutions. I have a couple of questions about DB_DataObect in general, that were reaised by this thread. As I commonly refer to DB_DataObject as an alternative solution to my project, Propel, I wanted to clear up a few things so that I don't misrepresent, etc. I apologize if I ask a question that is clearly explained in the docs (just say "read the docs!" & i won't be offended :)

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....

This isn't really the point of my post, but why not just DAO -- or DataObject -- are there some other non-DB DAO solutions that might be confused? This whole thing w/ two db abstraction packages makes for some really messy naming -- MDB_DataObject, DB_NestedSet / MDB_NestedSet?. I guess this is just a requirement of PEAR's naming system, but it seems kinda problematic to have these category names match top-level package names. Further off-topic, I think it would be neat if PEAR took a Horde-like approach and required packages to have unique names rather than using category names (which seems to really preclude multiple implementations of the same tool)? I think that would work a little better since it doesn't make this assumption that the "DB" package is the definitive answer to database abstraction.

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.

So, am I correct in understanding that in the current DB_DataObject version there is no "official" way to generate DDL from an INI or XML file? I thought that you could use an INI file, but when I look at the docs it says something about not editing that file directly (plus the BIT arithmetic isn't particularly user-friendly). Does DB_DataObject support generation of DDL at all? or do you need to create the database first & then reverse-engineer it using createTables.php?

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)

Yeah, this is waht Propel does -- works off of XML to generate DDL. What is "structure" the INI file?

b) Database as the core design medium. - point generator at DB - generates MDBXML

    - in turn generates classes and structure.

Is this equivalent to what createTables.php does in current DB_DataObject? (but instead of writing to XML writes to INI file?)

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.)

Yeah, this makes least sense IMHO; I can't imagine this being quick especially if you're using metadata functions (which I assume you are?).

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,
    ...

);

Another, Propel-style, solution to this is to create (generate) db "Mapper" objects which provide a static OO representation of the database. (i.e. with methods like getTables(), getColumns(), getIndexes(), getForeignKeys(), etc.)

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..

Would using the MDB types help DB_DataObject support date/time types? Does DB_DataObject already support these types? I seem to remember that this was an argument for DB_Table, but perhaps am mis-remembering. Of course DB_Table doesn't exactly support date types either, rather represents them as strings. Thanks, Hans