Hi Hans!
On 07/09/2008 04:02 PM Hans Melis wrote:
> Tobias Schlitt wrote:
>> Simple relation prefetching
>> ===========================
>>
>> Change your current code
>>
>> $q = $session->createFindQuery( 'User' );
>> $q->orderBy( 'name' );
>>
>> $users = $session->find( $q, 'User' );
>>
>> foreach ( $users as $user )
>> {
>> $books = $session->getRelatedObjects( $user, 'Book' );
>> foreach ( $books as $book )
>> {
>> // Fetch authors...
>> }
>> }
>>
>> to
>>
>> $q = $session->createFindQuery( 'User' );
>> $q->orderBy( 'name' );
>>
>> $users = $session->findWithRelatedObjects(
>> $q,
>> 'User',
>> array(
>> 'Book' => array(
>> 'Author' => true
>> )
>> )
>> );
>>
>> // ... Foreach loops here ...
>>
>>
>> and the related objects are fetched with a join instead of single selects.
>>
> And where do the Book and Author objects go? I suppose they remain in
> the identity map until they are fetched. And how do you get them from
> the identity map? Do you still have to use e.g.
> $session->getRelatedObjects( $user, 'Book' ); ?
Exactly. The identity map takes (internally in
ezcPersistentIdentitySession) care about storing the fetched objects.
When you call getRelatedObjects() then, the identity map already has the
objects and returns them instead of issueing another query.
> I must say that this looks easier than what I could gather from the
> design docs and all the Set stuff.
The set stuff is only needed, if you intend to fetch just a subset of
related obbjects (not all). For example, if you want to fetch the top 3
sold books for each author.
> Another question I have is about performance. All related objects are
> fetched, so this could potentially get thousands of objects in memory.
This is, what the set stuff is for. I'll give you a (pseudo) code
example on what it might look like:
$selectQuery = $session->createRelationSetFindQuery(
'Author'
array( 'Book' => true )
);
This creates you a typical SELECT query object, which does not only have
the aliases set correctly for the Author class, but also contains the
join to fetch the Book objects, and according aliases. You can the add
(WHERE) conditions to this query as you like.
Since getRelatedObjects() is expected to return all related objects
(BC), it would not make sense to make it now return the limited subset
you defined. Therefore, you would need to give the subset a name:
$session->findRelatedObjects( $selectQuery, 'top_books' );
To retrieve the top 3 books of an author you now use:
$topBooks = $session->getRelatedObjectsSet(
$author,
'Book',
'top_books'
);
> Have there been any tests (or are they planned) to see how the identity
> map system copes with loads of objects? It would be nice to get a rough
> idea about the possible limits, that of course also depend on server
> configuration. But still, a reference would be nice.
There is no code, yet, that is why you just find a design document
draft, so far. I agree with you, that ending up with thousands of
(potentially not used) objects in memory is not a good idea. For this
reason, I introduced the set stuff. :)
If these features are used in a reasonable way, I expect it to be quite
performant.
Best regards,
Toby
--
Mit freundlichen Grüßen / Med vennlig hilsen / With kind regards
Tobias Schlitt (GPG: 0xC462BC14) eZ Components Developer
[EMAIL PROTECTED] | eZ Systems AS | ez.no
--
Components mailing list
Components@lists.ez.no
http://lists.ez.no/mailman/listinfo/components
