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
_______________________________________________
List: http://lists.rawmode.org/cgi-bin/mailman/listinfo/dbix-class
Wiki: http://dbix-class.shadowcatsystems.co.uk/
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/trunk/DBIx-Class/
Searchable Archive: http://www.mail-archive.com/[email protected]/
