On 16 May 2008, at 18:24, Jose Fonseca wrote:
> To reiterate, if scalar-ref update() behaved like that, we'd be
> protecting users from doing things like this:
> $cd->update({ last_played => \'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?
Often I do an update then you discard the obj so dont actually care
about the round trip/actual value.
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 = shift;
$self->update();
$self->discard_changes();
}
So it's not a really painful solution really.
Yes, that'd do it
** 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.
_______________________________________________
List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/[EMAIL PROTECTED]
