Re: pearifying metabase: phase 1

On Fri, 2002-02-01 at 18:40, Lukas Smith wrote: > Hi All, > > Just trying to get a list together here; any comments greatly > appreciated: > Structural differences (or better what will need to be added to metabase > to include or be compatible with pear db's features): > > You will find my naming of the "todos" to be a bit optimistic (resolved, > minor, small, large, unsure) but that is just a way to categorize the > different things > > This list might see some expansion in the future. Under resolved I will > list anything that will soon we included in Metbase, has just been > included or has been included for some time .. or more exact: anything > we don't need to worry about. The other categories should be self > explanatory. If needed we can always add another category: "extra large" > :-) > > So here it goes: > Resolved: > - Missing Drivers > Sybase (resolved: is coming) Does anyone have a Sybase test environment? > - get* family (resolved: with the latest release) > - placeholder function (resolved: metabase actually has had this for > quite some time) > > Minor: > - fetchmode (minor) > - DSN support (minor) > - Missing Drivers > Frontbase (minor?: will the frontbase guys write one/modify the current > for us?), > LDAP (minor: I want it myself, but the driver is fairly new and not that > "feature rich" yet, so we should be able to port it) > - tableInfo (minor: metabase allready has some of those features) Metabase has type abstraction that PEAR DB definitely should inherit. > - flexible default behavior (minor: shouldn't be too big of a deal to > implement) > > Small: > - Error support (small?: maybe not a big deal through the use if > customer error handler feature of metabase) > - transaction (small?: I haven't look at either metabases' nor pear db's > implementation) PEAR DB has autoCommit/commit/rollback. That's it. If people want a "startTransaction" method to disable autocommit, why not. > - DB_result object (minor) > - error messages (small?) What about error code mapping? > - getListOf (small?: Thomas was not sure about the status inside of PEAR > of these features) > > Large: > - LOB support (large?: I haven't look at either metabases' nor pear db's > implementation) PEAR DB uses placeholders (? or &) for this, but there are cases where special handling is needed. A few LOB regression tests would be nice. > - API changess like function naming, parameter orders, coding style > stuff (large: a lot of work but nothing too complicated) > > Unsure: > - storage.php (?: is this used a lot? Will this work out of the box once > we get API compatibility with PEAR DB? This could basically be > understood as another level of abstraction . maybe this is where the > LDAP handler should actually "attack" rather than as it is now in the > level of PEAR DB core that was meant for relational rdbms) I will split off DB_Storage as an independent package, so don't worry about it. > - different ways of how data is stored in the DB for emulated features: > sequences, NULL ..? (?: this is actually one of those most difficult > areas .. hopefully a simply convert script could take care of it . but > its definitely ugly if certain features have been emulated differently > in the db) > > Approach: > Dunno if this is crazy, but I would much rather not start off building > wrappers, but to actually work on a merged version that is easy to make > backward compatible with both abstraction layers (again as a warning > this is my first shot at merging two fairly large and estabhlished > projects - especially with opensource you gotta please the public or you > will face forks with would defeat the purpose of this merger - so I am a > bit nervous). > > Probably I will attempt at getting Pears DB.php to play nice with the > metabase_database.php :-) Heh, good luck Lukas :-) - Stig