Begin work on some extensive performance changes

[pnomolos]

This is the beginnings of some work to help with non-lazy/eager loading relations to reduce the number of calls to the database.

Right now there aren't any tests and not everything's working, but I wanted to get your thoughts as I was working on it.

This references issue #23

[vlucas]

So just to see if I understand everything, we are:

1. Collecting all the Entities in the collection
2. Seeing if they have the 'lazy' => false
3. Collecting all their 'child_key' fields
4. Selecting all related entities with those keys
5. Manually creating Collections of those entities by key
6. Setting those Collections back on the relation field of all the Entities in the original collection

DId I miss a step? Just want to get all this out here for discussion.

[pnomolos]

Yes, that's basically it in a nutshell. I took some inspiration from the ruby dm project with the naming. I'm not sure whether child_key and parent_key is better or foreign_key and (something else?)

[vlucas]

Is there any way we can use the same where array instead of introducing a new key to define? I think the required data is already there, just in a different format, right?

[pnomolos]

Yes, but I feel like the current where syntax is clunky to represent a join (and just a join) as every time we'll need to parse out the :entity (and :throughEntity) bits. I was imagining something down the line where you'd use the parent_key and child_key stuff to represent how to join the relationship, and use the where field to limit it. (So something like ...

'comments' => array(
    'type' => 'HasMany',
    'entity' => 'Comment',
    'parent_key' => 'post_id',
    'child_key' => 'id',
    'lazy' => false,
    'where' => array('status' => 'open')
)

This way you can both easily model the JOIN (when it's supported) or do it manually, as well as adding additional conditions should you want to.

[vlucas]

I actually think the current where clause for relations is what makes them so flexible. I think the issue we are really debating here is whether or not the relationship syntax should be modeled after what is expected in a JOIN, or if it should be modeled as a straight query. Right now, it's modeled as a separate query, which is why it uses the where array just like any other custom query would.