Re: MDB Questions - switching to MDB, failover and soon...

Before all this talk... - I have a few concerns relating to making DB_DataObject2 happen, I'm pretty sure in the short term, like alot of others on the list I always worry that there will be more talk, and less action (including me).. So I'm quite happy that the person doing DataObjects2 is left alone to drive it, at least while the enthusiasm is still there ;) *** actually the current codebase has not really been re-written as such, just heavily modified from the current code. ------------- Looking at the first implementation, the Database backend has been broken into drivers, currently 2 drivers exist at present, PDO, and PDO_mysql - I expect, that a wrapper to MDB would also be one of these. PDO_mysql looks at present looks a little redundant. The idea I see going forward, is that the PDO backend would provide - standard querying / connect / dsn->pdo mapping. - escaping features for all DB types (replicated from MDB or DB) - limit re-writing(replicated from MDB or DB) - sequence emulation.(replicated from MDB or DB) For the generator, it would have to use MDB2 for introspection. The reason for this code duplication, inside the PDO driver, is to try and make the core features more lightweight, - for most of the core, fetching and updating, it seems a huge overkill to force the user to include a large amount of code - lots' of file IO for each request etc., It should also simplify debugging a little... The other consideration is that DataObject2 will be designed without PHP4 in mind, (as the current DataObject provides a perfectly good PHP4 support). - and will not use the core PEAR class except as a last resort when loading config information. - It is planned to use PEAR_Exception though. - which makes supporting MDB2 a little kludgey for core operations. Other things that are still under consideration: - Drop all overload support.... - good idea at the time, but has proved to be more trouble than it's worth, and could be easily provided by a wrapper if someone wanted it.. - using query(NO ARGUMENTS) / rather than find() - new fetchAll( DB_DataObject2::OBJECTS | DB_DataObject2::KEY_VALUE | DB_DataObject2::VALUE | DB_DataObject2::SINGLE) - join/link - move code to external helper class... = I would really like this to happen, but doubt we have the resources for it. - change setFrom() to assignFrom() - to enable setters to be implemented (externally) without kludges) - raiseError - only Exceptions will be used... (actually this is how it works now) Feel free to add stuff to the list, but I'd rather we got to the point of the code being uploaded, and patches being proposed/recieved, than spending to much time discussing work that no-one volunteers to do... Regards Alan Matt Friedman wrote: > Sorry if I jumped to a conclusion without knowing all the facts. I'm > certainly not trying to be negative about DB_DataObject as we have > used it successfully for years. It's always been a great package. > > I think what I'm hearing, and please correct me if I am wrong, that > DB_DataObject2 is a rewrite for PHP5 only and is in the process of > being developed. Can I assume that since Lukas isn't aware of how > certain parts of the code will be structured in DB_DataObject2 that > the architecture hasn't been fully discussed on the list? If this is > the case (and I am purely speculating) then wouldn't it make sense to > do so before too much more development happens? Again, I'm guessing it > is being rewritten, and if so, IMHO does it make sense to take a step > back and look over the architecture carefully before-hand? > > I don't want to lie to anyone. I have a selfish agenda and that is > simply that we use DB_DataObject and I hope to see that DB_DataObject2 > achieves even more. > > Although I'm not usually a code contributor I wouldn't mind commenting > and contributing to design discussions, if its welcome. > > Many thanks, > Matt. > > > > > On 7/17/06, Lukas Smith <lsmith@php.net> wrote: >> Matt Friedman wrote: >> > It's surprising to hear that the new version won't use a driver >> > approach. Then I could use DB, MDB, PDO, or another, or even roll my >> > own. The author should consider how to structure the code to achieve >> > this architecture. Especially since it is php5, which supports those >> > types of oop patterns better than php4. >> >> Let me clarify my statements. All I have said is how I want the code >> structured compared to how the code is structured at the moment. Since >> DB lacks datatype abstraction Alan had to add this into DB_DataObject. >> This IMHO led to issues in the design. I prefer having the datatype (and >> some other abstraction aspects) inside the DBAL and not inside the ORM. >> >> I was not commenting on code for DB_DataObject2 that I have not seen >> yet. >> >> regards, >> Lukas >> >> > >