Re: If my database class is not MDB2-compatible, should I wait to release it?

On 18.11.2007, at 23:32, Inspired wrote:

Heya. I'm looking to release my first class on PEAR. In a tiny nutshell, it's an object-oriented database modeler. I did not originally write this class for PEAR, and so it uses a database abstraction class that I wrote that I would currently have to release as part of the class package. I've got no problems doing that; I think it even has several features that are not available in DB or (at least from what I've seen of it) MDB2. But the fact remains that my DB Model class is not currently compatible with MDB2. My question is, Should I propose the class now and see if I can get developers to start using it and testing it out, and then introduce MDB2 support in a later release, or should I hold off and wait to propose the class until I've added support for MDB2? What's PEAR's policy on this situation?

From what I have seen in previous discussions I would recommend to focus on PEAR2 right now. I think we have a decent set of DB interfaces for PEAR v1. MDB2 is PEAR v1 and anything PEAR2 would probably be based on PDO (with a port of all the added MDB2 functionality). If you are unaware of PEAR2 its a from scratch attempt with new regulations, likely targeted at PHP 5.3 (including namespaces). As a matter of fact I have already heard several people saying that they want to work on an ORM for PEAR2 and I have actually already seen some real world code I have been asked to review. Whatever DBAL/ORM put into PEAR2 will have to be rock solid and well maintained. So ideally all of the people working on a PEAR2 DBAL/ORM please come out of the wood work. Make sure you guys know each other and try to work cooperatively as much as possible. Maintaining a DBAL and ORM is not a one man project so the sooner people manage to group people behind some real world code to propose, the better for everybody involved. That being said, I do see the possibility of multiple ORM's in PEAR2 if they take a sufficiently different approach. regards, Lukas