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

Lukas Smith wrote:

Matt Friedman wrote:

Are you implying that we should wait for PDO support and go directly from DB -> PDO? Will it be simply another ini option? What are the advantages of PDO over MDB?

None of you want portability. Performance if you don't care about portability.

Actually its not even guaranteed to be bester. From what I have heard PDO is actually slower in most cases compared to the current RDBMS specific extensions. So depending on what you do in userland, it might end up being slower basing things on PDO. The main advantage of PDO is of course that something like MDB2 could be written with a lot less code to maintain. So I am not saying that PDO is pointless. However I fail to see what PDO really buys us as long as there is nothing like MDB2 based on PDO around. Overall I think its simply not worth it. MDB2 is solid and works. The only real benefit from a rewrite for PHP5 would be E_STRICT compliance (nothing I count as that big a deal) and returning Iterators be default (which can be achieved by setting the given option in MDB2). So IMHO we should focus on MDB2 for PHP5 and make sure we have a rewrite ready for the first beta versions of PHP6 in 2 years. It does however make a lot of sense to write a DB_DataObject2 based on MDB2 and MDB2_Schema. The only thing missing from MDB2_Schema is foreign key support and we could get rid of the IMHO dreadful ini files of DB_DataObject2 and instead replace it with a solution that caches output from MDB2_Schema xml schema files. If we stick Alexey's and Betrand's Quickform rewrite in front of that, we have a real Ruby On Rails killer that would enable people to use abstract datatypes in their xml schema files like "email", "phonenumer" etc. and get automatic SQL DDL generation, CRUD SQL generation, form and validation generation. With some additional work on the xml schema format we could even embed some workflow information into it to make the form/validation generation even more powerful. regards, Lukas