[Dbix-class] REPOST: memcache / DBIx::Class

[Brian Kirkbride]

Brandon Black wrote:
> If we have a real PK/UNIQUE column to key on, we can probably reliably
> invalidate the cache on ins/upd/del of that key, which makes for a
> consistent cache model within that limited usage.  We could probably
> do special cases for "SELECT * FROM foo" too, and just invalidate on
> any ins/upd/del on anything in the table.  This is a very simplistic
> but useful caching model, where the PK/UK value is the key, and the
> object's data is the data.  You could probably even extend it to cache
> objects returned by a complex search by their PKs as they are fetched
> via the ->next iterator too.
> 

I agree, this is the easiest and most direct way to map a cache key to a cache 
entry and it's easy to hook into the ResultSet to add to the cache.  If a cache 
keyed off of PK only cached on ->find that wouldn't be very useful.  But hooking 
into ->next and ->all in ResultSet would probably be pretty effective.

> An even bigger issue with this is that there probably isn't a general
> solution that also covers update/delete with complex where clauses, as
> opposed to update/delete of a specific key. (As in, "UPDATE people SET
> account_type=30 WHERE person_id > 200", or "DELETE FROM people WHERE
> person_id > 200").
> 

This is true though, meaning that UPDATEs or DELETEs that aren't PK apparent 
should invalidate all cache entries for that table.

On a somewhat related note, I've never understood why relationships don't save 
roundtrips to the database when possible.  It may be a consistency issue that 
I'm not seeing, or possible DBIC does do this and I just don't know how to 
"encourage" it.  When I do:

# generates a query
my $foo = My::Schema->resultset('Foo')->find(123);
# generates another unless prefetch is set for Foo
my $bar = $foo->bar;
# much later in different code context, generates another query for Foo(123)
my $foo2 = $bar->foo;

shouldn't I get $foo2 without a trip to the database?

Assuming that Foo has_a Bar and Bar belongs_to Foo, of course.  Maybe there's 
just no good way to tell from the relationship meta data?

- Brian