Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[DDC-1398] Extra-lazy get for indexed associations #706

Merged
merged 7 commits into from
Jun 20, 2013

Conversation

sandermarechal
Copy link
Contributor

If an association is EXTRA_LAZY and has an indexBy, then
you can call get() without loading the entire collection.

If an association is EXTRA_LAZY and has an indexBy, then
you can call get() without loading the entire collection.
@beberlei
Copy link
Member

<3

throw new \BadMethodCallException("Selecting a collection by index is only supported on indexed collections.");
}

return current($persister->load(array($mapping['indexBy'] => $index), null, null, array(), 0, 1));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you need to handle the case of non-existent keys properly: the Collection interface wants to get null in such case, not false (which is what current returns when the array is empty)

@stof
Copy link
Member

stof commented Jun 20, 2013

you could also implement containsKey this way, checking if an element is found


$queryCount = $this->getCurrentQueryCount();

$user->articles->get($this->articleId);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can you test for the actual data being returned as well? in the second test as well

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

and please also add a test for non-existent keys

The load() function already returns just one entity or NULL, so
the current() is not needed and the result can be returned directly.
@sandermarechal
Copy link
Contributor Author

I think I fixed all the things you pointed out. I'm looking at implementing containsKey as well.

@sandermarechal
Copy link
Contributor Author

I am not sure what the best way is to handle containsKey. I see three possible options:

  1. Simply call get from containsKey and check for NULL. This is simple to implement but it will load the actuall entity (which may have FETCH_EAGER associations, causing more data to be hydrated, etcetera).

  2. Query the database directly. This is what I have been working on so far. It works, but looks ugly. There is significant code overlap between containsKey and count and I don't see a non-ugly way to reduce it, except for option 3.

  3. Extend the count API to accept additional conditions and/or Criteria. In this case containsKey could simply use count with an extra condition and check if the result >= 0. Downside is that it is more work and that it is an addition to the API. On the upside, this sounds like a nice feature to have. People would be able to do things like this on a collection, and it would work properly on extra lazy collections as well:

    $numUsers = $group->users->count(array('active' => true));
    

So, what do you suggest?

@beberlei
Copy link
Member

@sandermarechal Lets keep containsKey for another time, we have something very useful here already. One thing I would like to see is the Persister Collections to use find() instead of findBy() to use the identity map, if the index-by is the identifier field. Otherwise its already awesome

@sandermarechal
Copy link
Contributor Author

@beberlei: I'm sorry, I don't quite understand what you mean. I'm not using find() in this PR but I am using load() directly.

Do you mean fixing the TODO at BasicEntityPersister->load() on line 742?

@beberlei
Copy link
Member

@sandermarechal yes, please use the EntityManager#find instead if index-by == identifier field. This will greatly enhance performance in some use-cases.

@stof
Copy link
Member

stof commented Jun 20, 2013

@sandermarechal regarding your propsal above, I don't think count() should be changed. It is the implementation of Countable

@sandermarechal
Copy link
Contributor Author

@beberlei Done

@stof Good point. I didn't think about Countable. Anyway, I will make a separate PR for containsKey so this can be merged.

@beberlei
Copy link
Member

@sandermarechal i am afraid you need to add more tests now ;) the article stuff uses articleIds, so its never triggering the collection persister get calls anymore

@sandermarechal
Copy link
Contributor Author

@beberlei Yup. Done.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants