MDB manager "abstract"

Hi, As promised a couple days ago: Here are my thought on the changes necessary in the manager. ** Disclaimer I have thought about these things since quite sometime, but I only sat down this evening to start to get some structure into my ideas. Anyways the following is a result of 1 hour of typing this evening. Also everybody that wonders why the hell MDB requires you to morph your database let me say the following: IT DOESN'T! The morphing is only required if you want true portability. You can use MDB just like for example your good old PEAR DB that for the most part just provided a wrapper around the various RDBMS interfaces. MDB does not require you to make use of the type conversion or the schema management. This is all optional. If however you do want to use those features you will have to make the necessary adjustments. But don't worry MDB is here to help and with MDB_frontend you will not even have to touch an editor. ** Manager Feature List The main purpose of the manager is to manage DB schema's independent of any specific RDBMS. It should be able to do the following: 1) create a database from an schema - tables - fields - indexes - sequences 2) alter existing databases if the underlying schema has changes 3) dump databases - content - all - only certain - strucutre - all - only certain 4) morph an existing non MDB/Metabase compliant database to a MDB/Metabase compliant database 5) provide easy methods to read data from a schema file - tables - fields - indexes - sequences 6) provide methods to change only certain parts of a database and them written to the schema file - tables - fields - indexes - sequences 7) sync two databases - sync the structure - sync the content Most of the above features are allready implemented via the methods updateDatabase() and dumpDatabase(). Actually 1) and 2) are quite completely provided by updateDatabase(). At the moment 3) and 4) are provided by dumpDdatabase(). However, 4) requires interactivity to work correctly, because MDB cannot resolve certain datatype ambiguities. MDB currently uses the "best guess" and issues a warning, if any ambiguities are encountered. Also MDB currently cannot really morph the data within the database correctly. For 5) has the necessary internal logic but lacks an API to access that functionality. There are methods that do half of what 6) calls for. They are private methods ATM. Unfortunately the way they are currently implemented these changes will not be written to the schema file. Therefore I propose the following changes: - dumpDatabase() - will not be able to reverse engineering anymore - will require an existing schema file so that all data can be converted to MDB native data before dumping - will allow optional parameter that specify which tables, sequences and indexes to dump - this should be doen as flexible as possible (regexp, list of which to include and/or list of which to exclude) - loadSchema() - add this method to load a schema into an array - the reverse engineering - methods in manager_*.php should be moved to a seperate extension (reverse_*.php for example) - should read a database and list all choices resulting from ambiguities - it should provide for methods to make those choices - should also work if no choices have been made (therefore the first choice will be used) - it should be able to create an xml schema file and convert data from any RDBMS native datatype to MDB's native datatypes - it should be able to alter an existing database and all its content from any RDBMS native datatype to MDB's native datatypes - it should have methods to list all required changes - add public methods that can change an existing database - these can use the existing private methods, such as _createTable() - also write those changes to the currently loaded schema Basically this would alllow converting users can use the reverse engineering to morph their existing database to be MDB compliant. After that they will have a MDB/Metabase compliant database and schema file. After this they can make use of all the advanced features of MDB/Metabase like: - MDB/Metabase Core - type conversion - during querying - after fetching - MDB/Metabase Manager - RDBMS independant schema and data storage - automatic alterting of databases if the schema is changed The MDB_frontend can then be expanded to allow for browsing of database structure/content, altering of the database structure/content and (partially) dumping of database structure/content. It can also be used to morph existing databases to become MDB/Metabase compliant and provide hints to what needs to be changed in the application (like auto_increment is now a sequence etc.) Regards, Lukas Smith smith@dybnet.de _______________________________ DybNet Internet Solutions GbR Reuchlinstr. 10-11 Gebäude 4 1.OG Raum 6 (4.1.6) 10553 Berlin Germany Tel. : +49 30 83 22 50 00 Fax : +49 30 83 22 50 07 www.dybnet.de info@dybnet.de