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.
Thats a bit outside the scope of DB_Dataobject :) - It's a decision that
was made early on in pear, and at present, the advantages of the current
design outweight the problems it caused.
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? Nope - From the beginning, the existing database has always been the source generator for the schema. (eg. SQL was designed as a DDL, so I thought why not use it ;)
I did attempt to investigate the feasibility and use of an XML DDL, with Gtk_MDB_Designer, and MDB.
However it ran into some serious maintenance issues, which have generally put me off using it as a 'source' for the schema information
** little story.
The initial design of a project I did, the database was done using gtk_MDB_Designer, and in the early stages, I would just wipe out the database, and rebuild the structure from the XML files.
However, as we entered beta testing stage, with live data, and real users. dropping the database every time we made a adjustment to the structure became unfeasible. (as live data was now being used)
MDB XML has some features for altering tables, but the more you changed the database, the worse, the schema became..
(eg. imagine an medium size project)
40 tables:
10 columns deleted from various tables over time.
20 columns added to various columns over time,
10 columns renamed in various columns over time. (and some renamed more than once...)
Not only did MDB ( at that time ) have serious problems with booleans, and quite a few other types, that caused the changes to create borked tables. But the XML Schema became far more complex, and added no value above and beyond, just sql dumping the schema. (and keeping notes of changes in SQL Format..)
From that experience, I would almost never suggest keeping database schema in any place other than in the database... - But I know a few others like to think it is feasible... - so the long term plan is to support this..
The XML schema is however very usefull for dumping schema, and recreating it in other databases...
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).
Bit arithemetic is alot faster than string compares.. - and uses less memory.. - thats the logic behind it..
Does DB_DataObject support generation of DDL at all?
Nope. (that's another packages responsibility....)
or do you need
to create the database first & then reverse-engineer it using createTables.php?
Yeap.
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?
See story above about why this is a great idea, for open source type large projects, but is painfull and unproductive for custom solutions.
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?)
Yeap. - this is the prefered idea for XML Schema storage (as a repository for rich data to be used to install the database), and a lightweight PHP array or INI file, to store the required info for generating SQL.
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?).
not too bad, the queries are cached, and alot of the time, you dont query that many tables.
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.)
The whole 20 classes thing (sorry this is probably an exageration), is something that tends to put me off solutions like propel, if there is no simple API that provides 99% of the requirements in a single class, and anything else is an add on (eg. a seperate package).. then I get the sense that the author is trying to solve too many problems.
Would using the MDB types help DB_DataObject support date/time types?
Nope..
Does DB_DataObject already support these types?
Yeap pretty comprehensive and well tested Date/time/datetime/mysqltimestamp support. (for native types only!.)
Regards
Alan
Thanks, Hans
--
Can you help out?
Need Consulting Services or Know of a Job?
http://www.akbkhome.com