Prepared statements cache about firebirdex HOT 2 CLOSED

I am opposed to caching prepaid statements at the client for the following reasons

• It would be complicated
• It uses a lot of memory
• Can't handle statement processing leaks well?

Since db_connection's handle_decrate() and handle_deallocate() handle the equivalent of Firebird's statement handles, wouldn't it be better for functions that use db_connection to cache them?

from firebirdex.

• It would be complicated: Maybe I'm overlooking some of the complexity, but hashing the statements and using the hash as a key in an ETS table does not seem to be so complicated at first sight. Where exactly do you see the complexity? (Of course I'm willing to help out)
• It uses a lot of memory : I will have to figure out how much memory is used to cache a statement, but memory use could be limited by max_prepared_statements and cleanup of oldest or least used statements when the maximum is reached.
  And of course there is still the option of completely opting out of prepared statement caching with a keep_prepared_statements? connection option, defaulting to false, or setting max_prepared_statements to 0.
• Can't handle statement processing leaks well? : I don't really understand this one.

Since db_connection's handle_decrate() and handle_deallocate() handle the equivalent of Firebird's statement handles, wouldn't it be better for functions that use db_connection to cache them?
Isn't it Firebirdex that is using the DBConnection functions, and therefore indeed a good candidate to do the caching?

I'm just launching an idea. I'm perfectly fine if you don't like the idea, and want to close the issue. I can still do a prepared statement cache outside of Firebirdex. No hard feelings at all, and very grateful that you have created this great library.

from firebirdex.