Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:28422
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain tonybibbs.com designates 216.51.246.17 as permitted sender)
Message-ID: <45FE9568.4070509@tonybibbs.com>
Date: Mon, 19 Mar 2007 08:51:36 -0500
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To:  internals@lists.php.net
References: <1174134488.8667.33.camel@lena> <45FC74A5.6080307@pooteeweet.org>
In-Reply-To: <45FC74A5.6080307@pooteeweet.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] google SoC - dbobj
From: tony@tonybibbs.com (Tony Bibbs)



Lukas Kahwe Smith wrote:
> IMHO a full ORM belongs into user space and not into C code. I kind of 
> like the approach that ADODB did, which was taking an existing DBAL and 
> moving selected items that where bottlenecks into C space. Thereby 
> providing a drop in speed improvement, while keeping the C code to a 
> minimum.

I agree.  I'm a user of Propel (http://propel.phpdb.org) which is in the 
user space as you suggest and I think it works fine.  The current beta 
version of Propel uses PDO so execution speed isn't really a huge 
problem.  I think the only thing worth considering adding to the C-code 
is something to compliment PDO that can collect all the database 
metadata that ORM's require.  Propel currently does this using Creole 
(one of the many DB abstraction libraries out there).

> As such I would prefer that this would be done in collaboration with an 
> existing or in development PHP ORM.

Again, I agree.  And being a bit biased I'd simply like to throw Propel 
into the mix for consideration.

--Tony