Re: Re: DB_DataObject and MDB

Hi Paul, Paul M Jones wrote:

Yeah, it'll be a pain. I'm just thinking of how some databases allow you to change more information about a column than other databases. In many cases it may require creating a new column and dropping the existing one or something ... could get ugly.

I am discovering that is exactly what is necessary when changing the schema for a datatype-abstracted system. It seems that to completely abstract column changes over the 6 RDBMS systems for DB_Table, you have to... 1. Create the new column with the new settings (name, size, whatever) 2. Copy the values from the old column to the new 3. Drop any indexes on the old column (MySQL becomes a pain at this point) 4. Create indexes on the new column And in that order, too. If you are modifying the data, you have to figure out manually if it's better to do it on the old data first and then copy, or copy then update (the presence or absence of indexes is what drives the decision). The space issues with this approach can become, shall we say, problematic ... but it does seem to work on everything.

That's good to know that it works accross databases. I think that's probalby the solution we'll take, then. It certainly is a pain, but I'd like to eventually support automating that stuff.

Sure, it's a great starting point. XML also has the advantage of being particularly suited to storing more information than needed -- making it a great way to drive things like forms, etc.

Embedded arrays have the same advantage (c.f. DB_Table class properties, which carry info about form elements).

Well, in terms of the structure that's true. I'd say that XML has the advantage of XSLT, DOM, and XPath. For example you could have a master entity definition file (to take some Binarycloud lang) and use XSLT to generate a Propel data model schema (that validates using Propel's DTD) and use a separate XSLT script to create a form definition file, etc. My XSLT skills are quite weak, but having had opportunities to see it at work I definitely feel that XML is a nice way to store things. Furthermore things like DOM and XPATH add ways to work with those structures.

Does DB_DataObject already support these types?

Yeap pretty comprehensive and well tested Date/time/datetime/mysqltimestamp support. (for native types only!.)

Cool -- dunno why I remembered differently from DB_Table discussion. (I'm sure Paul will remind me.) Heh :)

Heh indeed. :-) At the beginning of the DB_Table proposal, DB_DataObject did not have them, but as the proposal discussion progressed over a few months, DB_DataObject continued to evolve and Alan added those types (and I added notes to the proposal text as he made them available, because I'm a fan of full disclosure :-).

That's what it was, ok. I knew you'd remind me. :) That's great taht DataObject supports date/time/timestamp types. Hans