in reply to Re^2: Caching DB rows transparently and with SQL search
in thread Caching DB rows transparently and with SQL search

I have no DBIC expertise, sorry.

Hopefully one of the grandees will answer here, I've send a PM to one of them.

> You can't memoize with a nested hash, as input, effectively can you?

Dunno!

Well the naive approach is to stringify the nested hash with Data::Dump or similar and to use it as a hash key.

But this will lead - like i said - to a lot of redundant data and you might need to free memory from time to time.

> I mean you can compare deeply but is that more efficient than hitting the DB?

IMHO only if you maintain index tables for key columns in hashes.

Like an AND condition being a hash slice of the two %indicies. OR a join of both %indices

But I'd guess there are already XS modules available offering in-memory SQL?

Does SQLite always operate on the filesystem?

Sorry im guessing here, I'm more an SQL user lacking deep knowledge.

Cheers Rolf
(addicted to the Perl Programming Language :)
Wikisyntax for the Monastery

  • Comment on Re^3: Caching DB rows transparently and with SQL search