Re^2: Caching DB rows transparently and with SQL search

I'm using Net::Clacks to cache database results, for example for my DNS Server.

But take note that i am biased, since i'm the author of Net::Clacks...

perl -e 'use Crypt::Digest::SHA256 qw[sha256_hex]; print substr(sha256_hex("the Answer To Life, The Universe And Everything"), 6, 2), "\n";'

Comment on Re^2: Caching DB rows transparently and with SQL search Download Code

Replies are listed 'Best First'.
Re^3: Caching DB rows transparently and with SQL search by bliako (Abbot) on Jul 07, 2020 at 07:18 UTC
Thanks for the pointer cavac. I did not know anything about this Clacks protocol. If I understand right, you use Net::Clacks for caching whenever a db request is needed/fetched. And that can be for multiple clients. You broadcast it, and clacks server deals with it. And has it available for all clients. In a client/server model. Fine, but what's the key? This is my primary obstacle in using (any) cache solution. Whenever I make a DBIx::Class db search I supply `($conditions, $attributes)` which are hashes for the search, which can be undef as well. So, one part of the key is the current function, e.g. `Model::User::list()`. The other part of the key must include some kind of digest of said function parameters. Which is not that easy to calculate efficiently and beat the db call ... bw, bliako	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^3: Caching DB rows transparently and with SQL search
by bliako (Abbot) on Jul 07, 2020 at 07:18 UTC

Thanks for the pointer cavac. I did not know anything about this Clacks protocol. If I understand right, you use Net::Clacks for caching whenever a db request is needed/fetched. And that can be for multiple clients. You broadcast it, and clacks server deals with it. And has it available for all clients. In a client/server model. Fine, but what's the key? This is my primary obstacle in using (any) cache solution. Whenever I make a DBIx::Class db search I supply ($conditions, $attributes) which are hashes for the search, which can be undef as well. So, one part of the key is the current function, e.g. Model::User::list(). The other part of the key must include some kind of digest of said function parameters. Which is not that easy to calculate efficiently and beat the db call ...

bw, bliako

[reply]
[d/l]
[select]