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

[John Napiorkowski]

--- On Mon, 5/5/08, Daniel Westermann-Clark <dwc at pobox.com> wrote:

> From: Daniel Westermann-Clark <dwc at pobox.com>
> Subject: Re: [Dbix-class] RFC: What to do with $resultset->single returning multiple rows?
> To: jjn1056 at yahoo.com, "DBIx::Class user and developer list" <dbix-class at lists.scsys.co.uk>
> Date: Monday, May 5, 2008, 8:33 PM
> 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


      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ