Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:36206
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain pooteeweet.org from 85.10.196.195 cause and error)
Cc: =?ISO-8859-1?Q?Bank=F3_=C1d=E1m?= <thefirstofall@gmail.com>,
 Richard Lynch <ceo@l-i-e.com>,
 Guilherme Blanco <guilhermeblanco@gmail.com>
Message-ID: <8885A02C-E4AA-41D7-A817-CCA2DB859255@pooteeweet.org>
To: PHP Developers Mailing List <internals@lists.php.net>
In-Reply-To: <bcb7aa500703200643n5c5cf0d5x2c3794d2906c531f@mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v919.2)
Date: Wed, 19 Mar 2008 10:20:02 +0100
References: <1174134488.8667.33.camel@lena> <45FC74A5.6080307@pooteeweet.org> <1174231834.12274.110.camel@lena> <45FEBD70.2090000@zend.com> <1174330743.9134.2.camel@lena> <41721.216.230.84.67.1174341117.squirrel@www.l-i-e.com> <1174342387.14657.86.camel@lena> <bcb7aa500703200643n5c5cf0d5x2c3794d2906c531f@mail.gmail.com>
X-backendmedia-com-MailScanner-Information: Please contact the ISP for more information
X-backendmedia-com-MailScanner: Found to be clean
X-backendmedia-com-MailScanner-SpamCheck: not spam, SpamAssassin (not cached,
	score=2.372, required 6, AWL -1.16, FH_HELO_EQ_D_D_D_D 0.50,
	HELO_DYNAMIC_IPADDR 2.94, RDNS_DYNAMIC 0.10)
X-backendmedia-com-MailScanner-SpamScore: ss
X-backendmedia-com-MailScanner-From: mls@pooteeweet.org
X-Spam-Status: No
Subject: Re: [PHP-DEV] google SoC - dbobj
From: mls@pooteeweet.org (Lukas Kahwe Smith)

Hello Banko,

I remember that you proposed an ORM written in C/C++ last year around  
the same time. Back then I was quite opposed to the idea, saying that  
something like this best belongs in userland, and that at most certain  
bottleneck features should be moved to C (following the example of the  
ADODB optional companion extension). I still believe this to be true.

However my opinions back then were a bit short sighted, as I focused  
on the fact that a proper ORM needs a proper DBAL underneath to really  
work. As such I feel that PDO does not fulfill this requirement, and  
actually I think it never will/should do this. Like I stated back  
then, database sql abstraction is ugly, tedious and hacky. This is  
something the user should be able to easily and quickly adapt to his  
needs. However one line of thought I ignored back then (and I do not  
remember anyone pointing this out), is that of course such an ORM  
could leverage a userland DBAL that follows a defined interface. I  
think such an approach could indeed be feasible. Then again writing an  
ORM in C is a huge undertaking and maybe again the best approach would  
be to pick an existing ORM and start a companion extension that one by  
one replaces the bottleneck areas with a C implementation. One day  
this might lead to a full fledged ORM in C, but in the mean time it  
already provides real world benefits.

regards,
Lukas