|
in reply to Re^3: Tricks with DBI
in thread Tricks with DBI
I'm using Class::DBI in conjunction with Class::DBI::Sybase. When using these modules they default to using prepare_cached for every query, and there is not an easy way to make them NOT to cache. I got it to work but by changing the Class::DBI code, which isn't good... Is there a way to force no caching, perhaps in a connection attribute? |
Re^5: Tricks with DBI
by mpeppler (Vicar) on Dec 25, 2005 at 09:05 UTC
|
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
| [reply]
[d/l] |
|
|
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!
| [reply] |
|
|
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.
| [reply] |
|
|
|
|
|
|
|
