Re: the future of database packages in PEAR

This looks pretty great based on a quick read of the docs. It does many advanced things native in the db abstraction layer that we currently do outside, such as locking etc... The only problem I found was to do with composite primary keys not contained within an association table. From: http://www.phpdoctrine.com/documentation.php?index=1.6#1.6.4 Composite Composite primary key can be used efficiently in association tables (tables that connect two components together). It is not recommended to use composite primary keys in anywhere else as __Doctrine does not support mapping relations on multiple columns__. DB_DataObject suffers from the same issue. It would be great, if pear is indeed going to adopt Doctrine as a pkg, if Doctrine resolved this issue. Not sure if Doctrine can support auto-fail over scenarios, but it would be great if this was done also. This is a scenario we ran into recently but we couldn't get it done yet due to some limitations, (created by us :() Having a db layer that can do this sort of thing natively would be really useful. Just my 2 cents. Thanks, Matt Friedman. On 12/12/06, Arnaud Limbourg <arnaud@limbourg.com> wrote:

Lukas Kahwe Smith wrote: Well its actually multiple packages compared to what we have in PEAR. Its essentially a DBAL, an ORM and a few other things at once. It would probably make sense to put it into PEAR as multiple separate packages. Here is an overview: http://swik.net/Doctrine Also PEAR should not be afraid of documented packages ;) Hehe, somehow it did not come across the way I intended. Documentation is a good thing indeed and that does not make me afraid :) It looks to me like a lot of code is needed to do things, this is what I got from the documentation.

Wouldn't it make more sense for people to support doctrine as one option and not the only one (that is what I understood when you say base PHP5 packages on it).

If you look at our current database package family we essentially have packages build on top of DB/MDB/MDB2 and other that are build on top of DB_Dataobject. Doctrine provides exactly this basis. I see what you mean now. I understand doctrine does what DB_Dataobject does, is that right ? An example would be a new doctrine datasource for structures_datagrid. Arnaud. -- PEAR Development Mailing List (http://pear.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php

-- -- Matt Friedman