[Dbix-class] Live object index support ported

[Matt S Trout]

On Fri, Jul 29, 2005 at 08:24:34AM -0500, Jason Gessner wrote:
> 
> On Jul 29, 2005, at 1:50 AM, Matt S Trout wrote:
> 
> >I've ported the Class::DBI live object index into DBIx::Class as
> >::CDBICompat::LiveObjectIndex. Notable changes are -
> 
> Since there was always a constant question from SOMEONE about the  
> live_object_index, can we have a quick discussion about what it  
> actually does and if it is useful to keep it?
> 
> It isn't a cache per se.
> 
> Does it help keep 2 objects that are really the same row in sync?  If  
> so, what is a good reason for even having 2 objects that refer to the  
> same row, in the same process at the same time?

Basic purpose: to ensure that if you grab the same record somewhere in
your code while an object for it is still in scope somewhere that you get
back the same object. It at least means you can't end up with 2 objects
that refer to the same row in the same process.

The thing is, if you stash away a bunch of objects to grab later, then
retrieve and update one of them separately somewhere else, without the
live object index you'd end up with them being two separate copies so
the the stashed one would no longer contain the correct values.

If you're not hanging on to objects yourself and using something along the
lines of an object/resultset cache (ala Sweet) then it's not that big a deal,
because your external cache has the latest one from across *all processes
sharing the cache* and if you're trying to sync between multiple processes
you don't really want each one keeping its own store of objects - but that's
down to the application code, we can't really stop them[0].

This is why people tend to turn the live objects index off under mod_perl;
because it can only enforce intra-process consistency and not inter-process
consistency it tends to become a problem quite quickly.

So, basically, under some circumstances it makes it a lot harder to shoot
yourself in the foot. Under other circumstances it makes it a lot easier
to shoot yourself in the foot.

We definitely need an implementation, because there're a fair number of
people out there whose code needs it, and when it's useful it's *very*
useful. But it's not core, and while it has to be loaded for "full compat
mode"[1], we may want two (three?) default recipes - one with LiveObjectIndex,
one with FastMmapIndex, and maybe one with MemcachedIndex or something else
cross-machine-ish.

At some stage we're going to have to figure out a decent way of mixing and
matching recipes. One possibility I've considered is delegation but having
the delegated classes built up as MI/NEXT.pm recipes as well.

Dunno. Ideas?

[0] Actually you could probably create an object that noticed it was old and
automatically refreshed itself off the db/cache (maybe by calling
$self->discard_changes) ... presumably check when get_column's called or
similar. But anyway.

[1] I suspect we actually want two standard compat recipes, a "full compat"
that people can drop in and know it'll by and large Just Work (I suspect
we can manage to support enough interface for most plugins to work straight
off. Sweet is a different matter but I have at least a passing acquaintaince
with the codebase so we'll be fine :), and a "mostly compat" that contains
all the "everybody uses it feature" that you can use + whatever specific
ones you want. Maybe just Core + ColumnGroups + the standard has_* stuff.

-- 
     Matt S Trout           Website: http://www.shadowcatsystems.co.uk
  Technical Director        E-mail:  mst (at) shadowcatsystems.co.uk
Shadowcat Systems Ltd.