Matt S Trout wrote:
In just some simple tests, we've been looking at (#2), there, for what
it's worth. It would seem that making ->resultset behave that way would
do the best at keeping it out of the way and making it DWIW.
However, my opinion probably doesn't weight very much here, since I'm
the guy that asked the original question :/
Why are you trying to cache -all- queries?
Mightn't it not be more efficient overall to -not- cache generic selects but
to always select only the PK and then cache the individual objects per PK?
You're going to need to do some serious thinking about your DB load and
what sorts of queries are (un)likely before you can tell what's likely to
be best.
OK. Great question.
So, to summarize, say we have a user with photos:
$user->photos ;
Those photos are the PKs of the photos.
For each one, we cache a photos object, one at a time.
Assuming we went that route, where in DBIC would we do that? Still in
resultset ?
a.k.a.:
my $photo = $schema->resultset('Photos')->single({ optional_field => 'foo' });
Is that what we're talking about here?
In that case we'd alter the creation of the schema object or the way
resultset works to look in memcache?
-Frank
_______________________________________________
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]/
