[Dbix-class] Scalar ref update()'s

Jose Fonseca zefonseca at gmail.com
Fri May 16 18:24:40 BST 2008


> To reiterate, if scalar-ref update() behaved like that, we'd be
> protecting users from doing things like this:

>  $cd->update({ last_played =3D> \'NOW()' });
>  print $cd->last_played;

The word "protect" is, in my opinion, not the right one here. It's not about
protecting the user, but about doing *the right thing*. Reason with me :
what sense does returning a reference to 'NOW()' make in Perl?

I think that, since the user CHOSE to use a scalar ref, he WANTS a round
trip to the RDMBS. Otherwise that returned statement is not wriiten in
Perl(it's SQL), why should it be returned as a value that can't be used in
Perl at all?

A technical solution would involve what Ash called "too much magic", and I
sort of agree**. Also keeping it in 2 functions would keep the system well
decoupled instead of bloating it up(TMM again).

Unless I'm totally missing something, I think the new function could be as
short as

sub update_and_refresh {
         my $self =3D shift;
         $self->update();
         $self->discard_changes();
}

So it's not a really painful solution really.

** The reason I don't agree completely is that, as explained above,
returning the scalar ref does not make any sense at all in update(). In my
opinion if we create a 2nd function, we should throw an immediate exception
when update is used with a scalar ref value to force it to break early and
let the developer know it's being used incorrectly. In my case I just wrote
that code assuming I'd get the date back because that scalar ref has nothing
to be doing in my Perl code.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/dbix-class/attachments/20080516/93f=
34a86/attachment.htm


More information about the DBIx-Class mailing list