Comments on: Lingering reservations about ORM

By: Agence de mode Paris

Agence de mode Paris — Sat, 11 Dec 2010 05:51:23 +0000

Your information about ORM.. is nice. I think that’s a great collection and defined in well manner. Thanks for posting.

By: carpet cleaning Virginia Beach

carpet cleaning Virginia Beach — Wed, 06 Jan 2010 15:05:36 +0000

thanks for the information on ORM… keep posting.

By: admin

admin — Fri, 04 Dec 2009 11:10:10 +0000

What you’re saying is more typified by the “bad code.” I get this user object and I also want some related stuff. I told it that and it gave me what I wanted but it decided to do it a really dumb way.

To be sure, the “good” code does look more like a SWL query.

I don’t think that ORMs should totally break away from SQL, at least not until we can have both clarity and decent performance from “telling it what you want.” and that presents another layer of communication. I can tell it what I want very eloquently with a high performing SQL query. Now I have to learn a whole bunch of new methods just to do what I can already do.

The ORM would have to be doing some kind of analysis of the code that is callig it to figure out that it need to join a bunch of stuff and then iterate through the results!

By: Mary Nicole Hicks

Mary Nicole Hicks — Fri, 04 Dec 2009 03:58:37 +0000

The problem with your good code is that you are using your ORM in more of a relational manner than Object Orientated. It looks like you just wrote a glorified SQL query.

I think ORMs still have not broken away from SQL enough. You should be telling the ORM what you want and it should decide to do the join.

I think a ORM call should be structure like this:
$user->comments()->NewsItems()->Rows

$user->comments() should not return a comment, but a ORM object. Internally the $user->comment() object should simple record “join user and comment tables where x”.

$user->comments()->NewsItems() should not return a NewsItem, but a ORM object. Internally the $user->comments()->NewsItems() object should simple record “join user, comment and newsitem tables where x and x”.

When $user->comments()->NewsItems()->Rows property is called it should then be able to join all required tables and only require 1 SQL query.

In your example it would do this:
$user = Core::getTable(‘User’)->find(1);
foreach ($user->Comments()->Rows as $comment)
{
print $comment->NewsItems()->Row->title . ”;
}

Only when Rows/Row is called would the ORM run sql Query. Until then you whould only be dealing wirh ORM objects.

By: admin

admin — Thu, 03 Dec 2009 20:13:26 +0000

Sorry about the typos, I just copied the example verbatim late at night without setting it up first because it brought the principal issue into such sharp focus. Will fix shortly. And I totally understand about making it database agnostic having to make a few sacrifices. Now you are making me itch to try V 2.0. My results were all based on 1.2

Truly Doctrine is the first one I’ve seen that exposes enough granularity without losing the X-plat abstraction so that I believe I could work with it. (and in a really rare critical situation I could write a non portable optimal query and just document it really really hard!) Keep up the good work!

By: ubieranki

ubieranki — Thu, 03 Dec 2009 17:59:09 +0000

Thispost is really interesting, I didn’t know all of this.

By: Guilherme Blanco

Guilherme Blanco — Thu, 03 Dec 2009 13:31:33 +0000

Hi, I am one of the core developers of Doctrine.

First of all, the “good code” misses a “C.” before “NewsItem N”. This is a requirement because it must know which relation it’s going to be considered. It’s not a top-level component.

I think everybody agrees that any ORM can bloat an application if used incorrectly. By taking advantage of an OQL (DQL is a proprietary OQL), auto load of relations are possible.
Of course we may suggest to not load the entire relations tree also, you must know what you’re doing.

Doctrine 1.X series is a bit bloated since it grouped LOTS of functionality. But I’d suggest you to take a look at Doctrine 2, which is a very well engineered solution based in JPAv2 (JSR-317) spec.

We internally apply lots of optimizations, but nothing better than a DBA allied in the project to point to exact places. That’s why we also provide a DBAL layer, allowing DBAs to play with the schema, including add indexes, constraints, checks, etc.
But you have to be aware that we need to have some guidance, and we always focus on most generic way. So an specific query may not be the optimal one for a given platform, but it works in all of them.

Keep compatibility with Oracle, MySQL, PgSQL, SQLite, SQL Server… arf… it’s not an easy task! =)

Anyway, good to see that we got some attention from DBAs also!

Cheers,

Guilherme Blanco