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

Re^5: Tricks with DBI

by mpeppler (Vicar)
on Dec 25, 2005 at 09:05 UTC ( [id://518984]=note: print w/replies, xml ) Need Help??


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

Not at the moment - though DBD::Sybase could be patched to alias prepare_cached() to prepare(). This would avoid the whole problem and disable prepare_cached().

In DBD::Sybase's Sybase.pm, right after the definition of prepare() (in the DBD::Sybase::db package)

*prepare_cached = *prepare;
That way any call to DBD::Sybase::db::prepare_cached() will really call prepare() instead.

Michael

Replies are listed 'Best First'.
Re^6: Tricks with DBI
by victor73 (Initiate) on Dec 26, 2005 at 08:54 UTC
    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!

      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...

Log In?
Username:
Password:

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

How do I use this?Last hourOther CB clients
Other Users?
Others musing on the Monastery: (4)
As of 2024-03-19 03:03 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found