Re: DB_Schema
| From: | Wolfram Kriesing | Date: | Tue, 22 Jul 2003 08:10:35 +0000 |
| Subject: | Re: DB_Schema | ||
| References: | 1 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-18520@lists.php.net to get a copy of this message | ||
in case there is any interest, here are some first steps on the DB_Structure
http://opensource.visionp.biz/DB_Structure.115.0.html
and here some reasons and more info where and how to use it with the DB_QueryTool 1.0
http://opensource.visionp.biz/version_1_0.117.0.html
Lukas Smith wrote:
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-- Wolfram ... opensource @ vision:produktion ... http://opensource.visionp.de ... authentication system .... http://sf.net/projects/auth