Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:28482
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <AF.D7.61497.277EFF54@pb1.pair.com>
To: internals@lists.php.net
Date: Tue, 20 Mar 2007 08:55:45 -0500
User-Agent: Thunderbird 2.0b2 (Windows/20070116)
MIME-Version: 1.0
References: <1174134488.8667.33.camel@lena>	 <45FC74A5.6080307@pooteeweet.org> <1174231834.12274.110.camel@lena>	 <45FEBD70.2090000@zend.com>	 <bcb7aa500703191244y7fb49e76t11c091e532ebcc60@mail.gmail.com> <1174340610.14657.67.camel@lena>
In-Reply-To: <1174340610.14657.67.camel@lena>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] google SoC - dbobj
From: dragonwing@dragonu.net (Jacob Santos)

I agree that the optimal solution would be a base ORM solution that all others 
can build off of and use. Just like PDO, it doesn't have to be an end all 
solution. Just implement the major features that all ORM projects have.

The mailing list is great to pick at the brains that have been building such 
solutions for years. Coming to a solution for a common API would be better in C 
as a PHP extension. It would also be easy to check for the existence of the 
extension to use it.

Jacob Santos


> Hello!
> 
> This paper seems to be interesting, but I don't have the time to read it
> now. If only there were such nice documentations when I started this!
> 
> On the performace point, I can't say anything well-grounded since I have
> no benchmark results. I'll do some when I have a little more time, then
> we'll see.
> 
> The other thing you mentioned ... the bundled ORM tool. I think it would
> be good to have a "standard sollution" over the current diversity.
> 
> An analogy came to my mind ... session handling and object persistence.
> Of course session handling is a much simpler task, I think they share
> some common points. Like both can be implemented in a number of ways.
> For session handling now there's a standard implementation that works
> good for allmost all cases.
> 
> I don't say, that a similar thing can be achieved for ORM, nor do I say
> that there should be one ORM implementation that everyone must use.
> However I think that currently the ORM palette is too diverged (like if
> everyone would use their own session implementation). There would be
> good, if there were some "standard" thing, that fit's most people's
> needs.
> 
> The bad thing is AFAIK that ORM is interpreted in many ways by PHP
> developers, so there can't be a one-fits-all solution. For example there
> are the structured programmer, who don't want to here about objects and
> classes, but want a nicer interface to access their data in their
> database. Taking these people into account when building an ORM is very
> important if we want to keep PHP an easy to learn language.
> 
> Than there are the people who do everything object oriented, want some
> of their objects to be persistent, and (for some reason) want them to be
> stored in a relational database.
> 
> And there a lot of people in between, who would use an ORM solution
> mixed with a lot of SQL.
> 
> I only mentioned three use cases, but in reality, I'm sure that the
> image is much more complex.
> 
> However I believe that a "common divisor" could be found, something
> common in all these cases, that can be made into some form of standard.
> This shouldn't have many features, but should be extensible.
> 
> I think if the different more developer-friendly solutions were built on
> "common divisor", it would result in better high level features, a nicer
> learning curve (don't have to start from 0 when you need to learn a new
> ORM implementation) and so on and so on.
> 
> What I'm really talking about, in the OO aspect, is a base class that
> provides only some very basic (but very important) ORM features. It
> should be small, quick and extensible. It should also have a really
> good, intuitive interface.
> 
> What you think?