mirror of
https://github.com/doctrine/orm.git
synced 2026-03-23 22:42:18 +01:00
DDC-408: accepting array of values per conditions rather than scalar only for find() and findBy() methods #507
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @doctrinebot on GitHub (Mar 11, 2010).
Originally assigned to: @guilhermeblanco on GitHub.
Jira issue originally created by user floch:
Regarding this post:
http://groups.google.com/group/doctrine-user/browse_thread/thread/ab48be395099dec9
it would be interesting to be able to pass array of values per criteria.
For example:
// retrieve 'user' role : Already works with current implementation of ORM
$em->getRepository('Entities\Role')->findBy(array('name' => 'user'));
// retrieve 'user' and 'moderator' roles : Not implemented yet
$em->getRepository('Entities\Role')->findBy(array('name' => array('user', 'moderator')));
@doctrinebot commented on GitHub (Mar 18, 2010):
Comment created by romanb:
The idea here is that this makes it easy to construct alternatives, so all conditions that look like "a = ? and (b = ? or b = ? or b = ? ... )", so every value that is an array would result in a parenthesized block of alternatives.
@doctrinebot commented on GitHub (May 12, 2010):
Comment created by shurakai:
I've fixed this within my branch:
c8f95f932aIf this change gets accepted, it should be available in trunk soon.
@Roman: Could you please take a look at the _transformIntoOneDimensionalArray method? I wasn't sure if there's a better way to achieve this, so maybe you want to change it. (I rejected using RecursiveIterators because we're only dealing with 2 dimensional arrays here)
@doctrinebot commented on GitHub (May 13, 2010):
Comment created by romanb:
Hm, I thought this would be easier, I forgot that we have to flatten the criteria, even if there is nothing to do (which is most of the time).
I also think it would be more useful to expand this a bit to a more generalized concept, allowing to compose all sorts of simple criteria, including <, >, <=, >=, <>, ...
Maybe we can address both issues by some new (optional) way to construct the conditions for the find*() methods, i.e. with expression objects or special arrays or whatever, so that we can also cheaply identify these criteria for sql construction, any ideas are welcome.
As it is now, I don't think we should include this.
ps. A side note about the test in the commit: It is silently relying on a specific order of the objects in the result but you can generally not rely on this. The order may not be the same as the order in which you invoked persist() on the objects between all the different database platforms. In general, you can only assume a guaranteed order if the SQL/DQL statement contained an explicit ORDER clause, otherwise there is no guarantee whatsoever about the order.
@doctrinebot commented on GitHub (May 19, 2010):
Comment created by romanb:
Unscheduling as implementation is unclear.
@doctrinebot commented on GitHub (May 21, 2010):
Comment created by shurakai:
Stopping progress until we've discussed this issue.
Roman, do you want this to be included in the final 2.0 release or should this be moved to 2.1? I totally cannot estimate the effort and whether it's worth it.
@doctrinebot commented on GitHub (Aug 14, 2011):
Comment created by @guilhermeblanco:
This issue is now fixed by commit
63a2f02f4dCheers,
@doctrinebot commented on GitHub (Aug 14, 2011):
Issue was closed with resolution "Fixed"