[Dbix-class] Found it: How do I set disable_sth_caching?

Louis Erickson lerickson at rdwarf.net
Wed Nov 15 14:57:20 GMT 2006


First, a thank you to yourself and Matt.  I appreciate the replies.

I'm working with Firebird.  This means I'm using DBD::InterBase instead of 
one of the more common ones.  While Firebird/InterBase usually works well, 
it tends to do things just a little differently than the other databases.

On Wed, 15 Nov 2006, Brandon Black wrote:
> The dev version really is a dev version, its not recommended that you
> use it unless you're really familiar with DBIC and on IRC all the time
> and willing to fix things in it and send us patches, etc.

Okay.  I'm not quite there, although if I keep wading through problems 
like I've been having I may be on the way.

I may wind up with a new DBIx::Class::Storage::InterBase that allows 
automatic primary keys.  It's a little different than the other 
implementations, and has to override insert() instead of just providing 
last_insert_id.

> As Matt said, we'd be really curious as to why you need sth caching
> disabled.  I've got one known use-case for disable_sth_caching that
> involves PostgreSQL table inheritance, 

I also noticed in the dev version of the code that it's used in 
Storage::NoBindVars to prevent caching of way too many handles.

> but I haven't heard of any others that are really good.

It appears that prepare_cached does not behave properly with it in all 
cases in DBD::InterBase.  

In the long run the right answer is getting that fixed, but disabling
prepare_cached will let me keep making progress while I try and solve the
underlying problem.

I now have a simple program which demonstrates this problem.  I can 
provide much more information if you'd like.  I have a little more 
research to do and then I will be trying to discuss this with the DBD 
maintainers.

> We've also been discussing adding Tie::Cache::LRU to the sth cache in 
> the dev version to limit the otherwise potentially boundless growth of 
> the cache as well in some cases.  This may bear on what you're doing as 
> well.

I hadn't noticed that class.  Skimming the docs on CPAN, it sounds like a 
good idea.  Is the right answer to use that in DBIx::Class or to update 
DBI's own prepare_cached to use it?

Considering that I think this is a DBD issue, and not a query structure or 
complexity issue, the change in caching shouldn't bite me.  The issue with 
the DBD will continue to do so, but I'm going to try and get that fixed.

Again, thank you both for your help!

-- 
Louis Erickson - lerickson at rdwarf.net - http://www.rdwarf.com/~wwonko/

Experience is the worst teacher.  It always gives the test first and
the instruction afterward.



More information about the Dbix-class mailing list