[Dbix-class] DBIx::Class and caching

[Matt S Trout]

On Thu, Jul 03, 2008 at 03:57:11PM +0400, Oleg Pronin wrote:
> DBIx::Class::Cursor::Cached is too slow for production use. It caches only
> data from DB making it impossible so store virtual data in objects and after
> fetching data from cache it has to construct a row object which is a
> expensive action for CPU, running all the 'inflate_result', and possibly
> other hard tasks.

We've had this conversation.

Cursor::Cached is designed to deal with *DATABASE TIME LIMITED CODE*

Also, because it's transparent to the resultset, it can be used to cache
a result that will be used both as objects or via HashRefInflator.

It is -perfectly- usable in production -if- your constraints are appropriate.

You're right, if CPU time is also a time limit for the same code path then
DBIx::Cursor::Cached is inappropriate. There is a huge gap between "not
appropriate in all situations" and "not for production".

I would love to also see a DBIx::Class::ResultSet::Cached that would
save the full object data using $schema->freeze/thaw but I've seen first
hand that in some cases this is actually just as slow because of the time
spent to reconstruct the object from its cached form, and Cursor::Cached
was a simpler and sufficient solution for the use case it was written for.

But if you continue to make unqualified statements that things are unfit
for production when multiple sites are happily using them for the purpose
given and they are merely unuseful for -your- requirements, I am simply
going to remove you from this list permanently as a troll; I don't have
the energy to reply explaining the same fucking things every time you
make this sort of useless comment.

-- 
      Matt S Trout       Need help with your Catalyst or DBIx::Class project?
   Technical Director                    http://www.shadowcat.co.uk/catalyst/
 Shadowcat Systems Ltd.  Want a managed development or deployment platform?
http://chainsawblues.vox.com/            http://www.shadowcat.co.uk/servers/