[Dbix-class] RFC: What to do with $resultset->single returning multiple rows?

[Daniel Westermann-Clark]

On 2008-05-05 17:19:01 -0700, John Napiorkowski wrote:
> -1- Revert ->select_single to the old behavior but deprecate
> -$resultset->single so that we can eventually remove it from the API
> -at some point, freeing us to constraint ->select_single when it's
> -no longer part of the public API
> 
> -2- Revert ->select_single to the old behavior and deprecate
> -$resultset->single for SQL that returns multiple rows.  Change the
> -carp to some sort of warn and fix the 'fetch without execute' bug.
> 
> -3- Revert ->select_single to the old behavior and properly document
> -the existing behavior, in particular to clarify the differences
> -between ->first, ->single, and ->find.  This is basically reverting
> -to the 0.08010 behavior, documenting it, adding a test, etc.
> 
> -4-> Push this change through.  Fix the 'fetch without excute bug'
> -and tell everyone they need to grep/ack through their code and
> -replace ->single with either ->first or ->find for the cases the
> -underlying SQL could return more than one row.
> 
> To be honest I prefer option 3, since that's the easiest thing for
> me and my deployment.  I really don't see much of a use for
> $resultset->single that only is useful against SQL that is
> guaranteed to return a single row.  Seems to me that is what ->find
> is for.

I think fixing the "fetch without excute" bug (non-MySQL-depdendent
tests would be appreciated) is the first step.  I've already updated
the docs for single to reflect the current state of trunk.

Also note that the carp is in fact a warning, but due to the "fetch
without execute" bug it appears more severe.

> However I do see value in a cursorless form of ->first, since
> sometimes you just want to grab the first thing as fast as possible.

This is the one point that I'm concerned about.  But as I asked on
IRC, why isn't find() working for you here?  If you're concerned
about speed in finding the first thing, you're going to want an index
and chances are good that it's a unique index.

-- 
Daniel Westermann-Clark