Beefy Boxes and Bandwidth Generously Provided by pair Networks
Clear questions and runnable code
get the best and fastest answer
 
PerlMonks  

Re^6: Tricks with DBI

by victor73 (Initiate)
on Dec 26, 2005 at 08:54 UTC ( #519086=note: print w/ replies, xml ) Need Help??


in reply to Re^5: Tricks with DBI
in thread Tricks with DBI

Thanks for the suggestion Michael. I'll stick with modifying Class::DBI since that seems less of a sin than modifying DBD::Sybase. In addition, we have many more dependencies on DBD::Sybase then on Class::DBI, which we're just introducing... Thanks again!


Comment on Re^6: Tricks with DBI
Re^7: Tricks with DBI
by Aristotle (Chancellor) on Dec 26, 2005 at 10:42 UTC

    Isn't all this other code just as broken if it uses prepare_cached with DBD::Sybase? And if it doesn’t use prepare_cached with DBD::Sybase, why would it be affected? And if you patch Class::DBI instead, wouldn’t that affect all CDBI apps, even those that shouldn’t be, like someone whipping up some quick using DBD::SQLite off at a corner of the environment? Patching DBD::Sybase seems to scope the fix to the right layer, whereas patching CDBI would be a scattershot that would affect code which shouldn’t be and miss code that should be.

    (Note: I’m not arrogating any say in your decision, just pointing out what seems like a mistake to me. The call is obviously yours since you’re the one who’ll have to live with the consequences.)

    Makeshifts last the longest.

      I was thinking about the OPs problem over dinner yesterday. I would imagine that the problem exists when you've got one handle open for read and you need to open another one with exactly the same statement. I wonder if prepare_cached could be changed to instead of just storing one handle, store an arrayref of them. When prepare_cached was called, it would go to the appropriate arrayref (via a hash lookup), and start iterating, calling $sth->{Active} on each until it finds one that isn't active, at which point it returns that one. If it fails to find an inactive one, it creates a new one and stores it. In the general case, you'd have only one stored. But, in cases like the OPs, it would just magically work. :)

      thor

      The only easy day was yesterday

      What you say indeed makes quite a lot of sense. However, I'm also contstrained in that I can't modify/patch DBD::Sybase. The admins are unlikely to touch it unless it's part of an official release... The only thing that I CAN control is CDBI, as it is part of a local installation and not centrally installed... I'm going to pursue the issue in the CDBI mailing list in the hope that there is some clever way of turning off prepare_cached... The perldoc makes it sound as if it should be easy, but it's not obvious how to do it without changing the code...
        Have your admins (or you yourself) contact me directly (email is best) to see how this might be fixed at the DBD::Sybase level.

        Michael

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others imbibing at the Monastery: (8)
As of 2014-09-19 17:24 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    How do you remember the number of days in each month?











    Results (143 votes), past polls