mirror of
https://github.com/doctrine/orm.git
synced 2026-03-24 06:52:09 +01:00
DDC-3527: Provide a method to retrieve exactly one entity out of entity repository #4344
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 (Jan 20, 2015).
Originally assigned to: @Ocramius, @guilhermeblanco on GitHub.
Jira issue originally created by user dominikd100:
Hello,
currently we have EntityRepository::findOneBy() method for retrieving a single or none entities out of an EntityRepository. It would be very useful, if there was a method which retrieves exactly one entity or throws NonUniqueResultException in case of multiple records returned or NoResultException in case of zero results returned (just like Query::getSingleResult() currently does).
Very often I find myself creating custom repositories for a couple of ::findOneByOrThrow() methods only. Needless to say it's quite mundane to do. The bodies of such methods follows the same pattern:
It'd be very nice to have it out-of-the-box in the base EntityRepository.
Thanks.
@doctrinebot commented on GitHub (Jan 20, 2015):
Comment created by @ocramius:
We actually want to reduce the repository API, not expand it...
@doctrinebot commented on GitHub (Jan 21, 2015):
Comment created by dominikd100:
Wow, ok. I guess you've got good reasons for it and I shouldn't try to convince you, that having methods for most common use cases out of the box is quite convenient?
If yes, then fine. I can create a common EntityRepository subclass for myself and put any helper methods I want there. This would at least cut down on the code duplication in my codebase.
If what you say is final, then we can close this ticket.
Cheers.
@doctrinebot commented on GitHub (Jan 22, 2015):
Comment created by @ocramius:
{quote}I guess you've got good reasons for it and I shouldn't try to convince you, that having methods for most common use cases out of the box is quite convenient?{quote}
The main problem is that adding API methods to repositories forces any subclasses to also apply eventual filtering logic to those as well.
Other than that, it's merely a question of interface segregation: the current API is hardly maintainable if we assume that many developers subclassed the
EntityRepositoryclass, therefore we should keep it locked until 3.x.I'll actually mark this issue for 3.0 and defer discussion till then.
@doctrinebot commented on GitHub (Jan 22, 2015):
Comment created by dominikd100:
Ok, thanks.
@ianfp commented on GitHub (Jan 24, 2016):
Perhaps you should consider changing
ObjectManager#find()to throw aNoResultExceptionif no entity with the given id exists. (In 3.0, obviously, since this would be a backwards-incompatible change.) This is the behaviour I want 90% of the time, and I believe returning null when you don't have to is considered bad OOP practice, no?What do you think? Am I totally out to lunch here?
@Ocramius commented on GitHub (Jan 24, 2016):
@ianfp I agree, but it's not the general case scenario.
findmeans "look for", therefore what you want is something likeObjectManager#get(), for example ;-)@ianfp commented on GitHub (Jan 25, 2016):
Yes! And while I understand your desire not to expand the API,
ObjectManager#get()would be really handy, and would not be a BC-break...:-D
@guilhermeblanco commented on GitHub (Jan 4, 2017):
The entire API is up for discussion for 3.0. This topic is already in the list to be revisited and decided.
Closing this for now.