RE: [PEAR-DEV] MDB2 and stuff

> From: Hundiak, Arthur [mailto:ahundiak@ingr.com] > Sent: Wednesday, December 03, 2003 5:18 PM > This is the first I heard of JDO for PHP. Always something new out there. > Does not seem like it will make it into the first version of php5. All I > could find was one scrap of sample code. In case I misspelled it, its name is "PDO". > PHP5 is certainly the wild card in all of this. Will it be released in > 2004? How compatible with PHP4 will it be? Obviously most OOP code will > have to be changed to run on PHP5 but will that delay it's wide spread > deployment? I don't have a problem with moving my stuff to PHP5 but I > can't > help but think that it won't be until 2006 or so before my ISP switches to > it. Well it will be out in Q1 2004 I am quite certain. PDO will probably not be in the first release but should be useable by the summer (probably with drivers for sqlite, mysql, pgsql, odbc and maybe oracle). Wide adoption on hosters sites should follow 12-18 months later. > I do think in terms of interfaces. And if we could come up with some more > or less standard connection,query,transaction interfaces then the > underlying > implementation becomes less important which, in theory, might make the > transition to PHP5 easier. Well on the other hand pdo will cut the amount of code needed in MDB alot and so the question is if multiple classes are more of a hassle then what they really offer. The thing every object will need to have a reference to the connection object with means in PHP4 people will have all sorts of opportunities to mess up the reference by copying instead of passing references. A transaction class might give the illusion of nestable transactions which may not be supported by the underlying databases (I need to check that one). Queries atm just consist of defining setting a limit, defining values (if you use prepared), defining the query itself and executing. Dunno if this is enough to warrant a new class, especially since the datatype specific stuff is moved into a separate class now already. The transaction class would be even smaller. A result class is supported now. What I do think makes sense is to provide a non-SQL OO interface which I will start addressing once I get MDB2 and DB_Schema/DB_Structure done. Actually with MDB2 I think a port of DataObjects should be trivial. > Anyways, ponder away. I would like to see a nice slimmed down database > abstraction object in PEAR. I know that proposing a new package would be > futile as we already have so many. Hence the desire to "work from within" > as it were. I appreciate you working this way. However I don't see where MDB2 would really get slimmer if you were to split things up. Right now the only thing you might not need which is in the core is the transaction handling. However a lot of it needs to be checked query related so there is little that could be taken out of the core. Then there is the sequence emulation, the subselect emulation and the replace emulation. So yes this does add up a little. I could move this sort of code into another module called "emulation" but the problem is that I don't have aggregation and in PHP4 I don't even have the interceptor __call(). So people have to write nasty stuff like $mdb2->[name of the module]->[method]. This is really painful and annoying. To the point where I have been pondering to move some code from the extended module back into the core. Regards, Lukas