DB_Schema
| From: | Lukas Smith | Date: | Mon, 21 Jul 2003 14:28:55 +0000 |
| Subject: | DB_Schema | ||
| Groups: | php.pear.dev | ||
| Request: | Send a blank email to pear-dev+get-18489@lists.php.net to get a copy of this message | ||
Hi,
I am still not tried to pester you all with questions and thoughts. This
time around I want to inform you all of the ideas that Wolfram and I
came up with.
The basic idea is that DB_Schema will get an accompanying set of classes
under the DB_Structure label. The initial idea was to build DB_Schema on
the same array structure as the Metabase manager uses.
However it became apparent that this limits the extensibility. Using
classes instead of arrays means that people simply implement an
interface and can then define new structures to their liking (like views
etc.). Also the user has more control about what types of nesting to
allow, what type of relations, and how to compute a diff etc.
Every structure element would be a class of its own which is an
implementation of that base interface.
Basically DB_Schema's responsibility would then to just call the given
reader and writer class. The reader class would build up a structure of
different DB_Structure classes. The writer class would dump that
structure. DB_Schema would in a sense that be a factory for this all.
One thing I am still cracking my head on how what sort of logic should
remain in the reader/writer. Obviously the reader/writer classes need to
handle different formats. At the same time they would also need to be
able to handle all of the cool things that people might add to their
DB_Structure classes. So maybe it would make sense to even have all the
reading and writing code in the DB_Structure classes and simply have a
generic reader/writer that could be in DB_Schema.
So basically the DB_Structure_Database class would define what structure
elements to look for when reading and then delegating the reading to the
relevant classes etc. Same goes for the writer classes. The code for
comparing two instances I already planned to keep in the DB_Structure
classes anyways.
Since Wolfram is also interested in using these classes at run time it
might make sense to maybe then offer an array representation of the
structure that could be cheapy (de)serialized.
So to summarize:
- DB_Schema would "blindly" called methods based on the interface
defined for DB_Structure
- there would be a class for every possible DB_Structure type
- obviously I would implement referece implementations for MDB's
purposes
- this would go nicely hand in hand with the separation of the datatype
handling in MDB 2.0
thoughts, comments?
Regards,
Lukas Smith
smith@backendmedia.com
_______________________________
BackendMedia
www.backendmedia.com
berlin@backendmedia.com
Linn Zwoch Smith GbR
Pariser Str. 44
D-10707 Berlin
Tel +49 30 83 22 50 00
Fax +49 30 83 22 50 07