Beefy Boxes and Bandwidth Generously Provided by pair Networks
Your skill will accomplish
what the force of many cannot
 
PerlMonks  

Re: Caching DB rows transparently and with SQL search

by LanX (Cardinal)
on Jul 04, 2020 at 11:56 UTC ( #11118908=note: print w/replies, xml ) Need Help??


in reply to Caching DB rows transparently and with SQL search

I suppose encapsulation of the desired queries in subs with memoizing isn't good enough because of the sheer amount of redundant data for different queries?

I found this very old SO discussion:

Does DBIx::Class have transparent caching

Hopefully it's of help. :)

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

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

Replies are listed 'Best First'.
Re^2: Caching DB rows transparently and with SQL search
by bliako (Prior) on Jul 04, 2020 at 12:29 UTC

    Yes, because at the moment I supply a hash of conditions and attributes for the DB search. You can't memoize with a nested hash, as input, effectively can you? I mean you can compare deeply but is that more efficient than hitting the DB?

    At a lower level (say, subclassing DBIx::Class's search as the link you cited suggests), it should be able to distinguish equivalent SQL even if they seem different (order, temp table names).

    But I now see clearer that it helps to constraint the searches and abstracting them before they are turned into SQL, before they even hit DBIx::Class will be much more efficient but creates a parallel universe of code in the app.

      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

Re^2: Caching DB rows transparently and with SQL search
by bliako (Prior) on Jul 05, 2020 at 11:12 UTC

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://11118908]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others surveying the Monastery: (2)
As of 2020-08-14 00:49 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    Which rocket would you take to Mars?










    Results (75 votes). Check out past polls.

    Notices?