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

Aaron Crane dbix-class at aaroncrane.co.uk
Fri May 16 11:35:30 BST 2008


Jose Fonseca writes:
> > Perhaps it would be useful to automatically reload on the next
> > access to an object with scalarref values.
> 
> Reading back from scalar ref'd update would need a round trip anyway,
> I don't see an alternative(using ANSI SQL at least).  This solution
> would delay the round trip up until no longer avoidable. Sort of an
> inverted COW (copy-on-write) for fields marked "dirty" after a scalar
> ref'd update.

I'm not convinced that even doing that is really a good idea.

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;

But if we think that such protection is of value, then that implies we
should also offer equivalent protection for code like this:

  $cd->last_played(\'NOW()');
  print $cd->last_played;

(I know that it seems a very unlikely thing to be doing, but if the
two lines are in different functions or methods or classes, I think it
could happen.)

I can't see any ways to offer such protection other than:

  - Throw an exception when someone tries to read a column that was
    set from a scalar-ref

  - Make another database round-trip to evaluate the expression, and
    then use that instead of the scalar-ref

The latter of those seems fraught with insurmountable problems (like
making sure you evaluate the expression in the right transaction at
the right time), so I discount it now.

And the former seems... draconian.  And not in a good way.

Assuming we can't offer the desired protection for the case where the
object is still dirty, what benefit is there in offering it for the
case where the object is clean?

I'm with Ash on this: an `update_and_refresh` method sounds like the
right solution to this problem.

-- 
Aaron Crane ** http://aaroncrane.co.uk/



More information about the DBIx-Class mailing list