[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