RE: [PEAR-DEV] MDB2 and stuff

> From: Hundiak, Arthur [mailto:ahundiak@ingr.com] > Sent: Tuesday, December 02, 2003 7:48 PM > I downloaded the code and looked it over. > It's certainly an improvement over MDB1 and DB. But I don't think you go > far enough. I know you are still trying to maintain some backward > compatibility with Metabase but I think you should consider moving towards > a > full OOP design. > > What I would like to see is a simple object (call it dbx for now) whose > purpose is to: > 1. Connect/Disconnect from databases > 2. Execute sql queries and return results. > > Currently your main object really mixes up defining queries, doing > transactions and processing results. These should all be broken out. Well there are 2 reasons why I dont think that this is necessary 1) I think the core of MDB is now trimmed down enough in terms of code size that I don't feel it is too problematic. Also I don't feel that the connection related code is really all that much. 2) with php5 will come pdo (basically PEAR DB implemented in C) which means a lot of code from MDB2 will become obsolete. Of course I will never make use of pdo in MDB2, however I will make use of pdo in a forthcoming release. This will immediately reduce the amount of code from MDB2 in the next release. > For example, if I want to set a limit on the number of records returned > then > I would go ahead and create a query object. Something like: > $dbx =& MDB2::Connect($dsn); > $query =& MDB2::CreateQuery($dbx); // Needs dbx because query objects can > have database type specific implementation > $query->setSQL("SELECT * from whatever"); > $query->setLimit(10,20); > $result = $dbx->execute($query->toSQL()); With setLimit() I see the only advantage with having a query object. However I think the current solution works well enough (that is that setLimit() defines a limit on the next query) > Not sure about prepared queries as I don't use them myself but they could > probably be in their own class. You cant separate the prepare stuff from the other query stuff, since some db's don't support the other and therefore you need to emulate. > Likewise, if I want to do transactions then I'd create a transaction > object > and send my queries through it. dbx does not need to know anything about > commits and rollbacks. Hmm there I could see some benefit. > Results of course should be returned as an object with methods for > fetching > rows and what not. I know creating the result object adds some overhead > but > overall I think it's worth it just to get all the fetching code out of > dbx. > It's possible that we may use the idea of having a Result class and an > ExtendedResult class depending on the needed functionality. That is possible in MDB2 now. You can get your results as objects. > Why? > First of all, I would like a small fast dbx class for doing most queries. > While MDB2 is an improvement it's still major overkill for my sort of > projects. I also think having a basic dbx class will lower the bar to > using > PEAR classes. I looked at DB when I first started out in php and said no > way am I going to use something with all that extra code in it. I am not > trying to write database administrator programs. I just want something to > do simple queries and updates. There's a gazillion dbx classes out there, > most could be replaced with a PEAR class. I find it confusing to work with too many objects. Especially if I have multiple open MDB objects. > Secondly, PEAR claims to be a set of classes which extend php. Fair > enough, > but OOP design goes beyond wrapping up functions in an object. I have a > hard time committing to a library which really does not follow basic OOP > principles. I monitor other forums and I think many other developers > share > this view. Of course .. however I dont feel that MDB2 is that bad :-) > Implementation > Can this be done without completely destroying the existing design? > Maybe. > There is probably no particular reason existing functionality could not be > tied up into wrapper class like you did for DB and Metabase. Be a pain > but > it could be done. Well I think it would be a pretty straightforward refactoring job. > Need directories such as > dbx (need a better names of course) > query > result > transaction > Each directory would then have a common class and overrides for specific > database types. Then basically split up the driver functionality between > these directories. > > Volunteer > I'm actually mostly interested in the next layer up where objects are > created from the database queries. However, if you think the idea of > breaking the main class up into smaller units has some merit then I'd be > willing to help. It would be really nice to have a standard way of > accessing databases. Well I have good reasons why I made things the way they are. However I do see some merit in the basic idea. For example in transactions I think it could really make it more transparent to the user. Hmm I will ponder. Regards, Lukas PS: I hope you are fine with me sending this reply to pear-dev as well because I feel that your ideas should get a larger audience than just me.