Re: New PDO-based DBAL/ORM for PEAR2
| From: | Bertrand Mansion | Date: | Tue, 20 Nov 2007 13:36:47 +0000 |
| Subject: | Re: New PDO-based DBAL/ORM for PEAR2 | ||
| References: | 1 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-48496@lists.php.net to get a copy of this message | ||
Le 19 nov. 07 à 16:57, Michael J. I. Jackson a écrit :
Please feel free to check out the code if you'd like to try it out or provide encouragement/suggestions/criticisms. The code is hosted on Google code, so bugs can be reported on the issues tracking system there (until it's ready to be voted on for inclusion in PEAR). Also, I'll be maintaining a wiki at that site that will contain details on how to use the package. I'd like to get a lot of people testing out the package and posting questions to the wiki so we can get a good idea what information the docs need to contain. Once we get a good set of wiki pages, it will be easy to port the content they contain to DocBook format. The package is very well documented and should be fairly easy to understand for anybody who's familiar with MDB2 and/or PDO.It looks good. I personally would remove the datatype and manager stuff, as well as most of the things related to SQL abstraction since this is a myth and adds bloat in the package (sequences and dates to start with). I'd call Drivers -> Connections and remove the singleton method. I wouldn't make a difference between one-to-one and one-to-many relations. I don't think subclassing PDO_Statement is needed. I am not sure a Query class is needed, everyone knows SQL. The Domain layer is a good idea but is hard to implement correctly in PHP. I'd add triggers after insert/delete/update/select (didn't find them, maybe it's in already?). I also have a PDO/ORM class but it doesn't deal with abstraction, so switching from MySQL to Oracle means you probably have to rewrite a few queries (the ones with outer joins for example, but limits are dealt with correctly). It looks a lot like yours but seems better integrated with PDO and PHP (uses little known PDO features and a lot from SPL). It uses delegates on overloaded methods and on ArrayAccess methods. It caches the database mapping on request. It can autoload object classes too. It works like this: Phreez::connect($pdo); // or Phreez::getConnection() if connection exists, accepts a connection id. $author = Phreez::fetchOne('author', array('where'=>'name = ?'), array('Jack Vance')); $book = Phreez::factory('book'); $book['title'] = 'The killing Machine'; $book->setAuthor($author); $book->freeze(); foreach ($author->getBooks() as $book) {
echo $book['title'];} Thanks to a Translation delegate, you can also do: foreach ($author->getBooks(array('order by'=>'title DESC')) as $book) {
echo $book['fr']['title'];
echo $book['en']['title'];
}
I first tried with decorators instead of delegates, but PHP has problems dealing with memory for the decorator pattern. And delegates are apparently faster in my benchmarks.
The main thing I miss compared to your package is the Domain stuff which means loading twice the same object from the database is unfortunately possible if user doesn't pay attention. I find it difficult to find a good way to deal with this issue so I will have a close look at your implementation.
Using pure SQL I can also do things like:
$authors = Phreez:query('SELECT {author} FROM author');
A the moment, my code is not meant to be open-source since it only support the databases I work with (mysql and sqlite3), it is not fully commented (but has unit tests) and the Domain stuff is missing so I can only help you with not so useful comments...
--
Bertrand Mansion
Mamasam
Work : http://www.mamasam.com
Blog : http://golgote.freeflux.net