[DBIx-Class-Devel] Optimized update_or_create

fREW Schmidt frioux at gmail.com
Mon Jul 15 15:06:45 GMT 2013


On Mon, Jul 15, 2013 at 11:13:40AM +0000, Peter Rabbitson wrote:
> This handwaving is exceedingly non-trivial. Read the source of find()
>

hah, ok.  Well, that's clearly the difficult bit.

> > I never needed create_or_update in any production code
>
> Same here, mainly because of its severe limitations: it takes only one
> argument, which is both used to find and to update. I would never trust
> myself to keep this in mind at all times and sanitize the input
> properly.
>

Same.

> > We already have code that behaves differently depending on context, maybe
> > void context can be used to detect if the users needs the row object, if
> > not use the optimized code path?
>
> This is a design mistake worse than the list/scalar behavior of
> resultsets. Please try to not perpetuate it further.

Agreed.

Ok, so with the above in mind, maybe a slightly different api would
be sensible.  How does everyone feel about this:

(name pending, though I'm leaning towards update_or_insert)

   $rs->update_or_insert( \%search, \%update, \%insert? )

The insert_hash is optional because if you have a simple enough case
the update and insert can be the same (though in my experience that is
often not the case.)

Another more flexible api might just be:

   $rs->search( \%search )->update_or_insert( \%update, \%insert? )

I almost want to just make that latter API and then add a helper or
two to expand to the former and others (maybe a version where you
specify the key and values of a given UC?)  Heck, in most of my
resultsets I tend to write a method to search based on the non-pk
uc's, so for me I'd do something like:

   $rs->search_by_name($name)->update_or_insert( ... );

--
fREW Schmidt
http://blog.afoolishmanifesto.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
Url : http://lists.scsys.co.uk/pipermail/dbix-class-devel/attachments/20130715/7720a074/attachment.pgp


More information about the DBIx-Class-Devel mailing list