>>>>> On 22 Jul 2001 12:41:57 -0700, "Jeff Zucker" <[EMAIL PROTECTED]> said:
Jeff> So, is this all a good idea and, if so, a) should I use
Jeff> something like
Jeff> $dbh->func($tname,'ad_close_table') method to give users control or just
Jeff> let the tables close with $dbh->disconnect and/or $dbh going out of
Jeff> scope, and b) should I support both methods of opening/closing styles to
Jeff> support other subclasses of SQL::Statement that want to stick with the
Jeff> old style?
I do think it's a good idea to try and solve, but I'm not sure it's
possible to solve easily and safely. I'm not a great fan of deviating
from the DBI api unless needed. If I was going to do the above func()
call, I'd probably make it optional but would default to closing all
tables after each update/delete statement executed unless the user had
specified in the DBI creation options that they would take care of
proper table closures.
Jeff> A side benefit of this approach will be that SQL::Statement will
Jeff> be able to send updated rows as single rows, not as an entire
Jeff> array of all rows which will be of great benefit to things like
Jeff> the AnyData::Format::SNMP that Wes Hardaker is finalizing.
These are somewhat unrelated goals, however. You're right in that
streaming multiple sets of update/deletes into a single series of API
calls would be beneficial. However, you run into problems with data
not getting modified when someone else changes it elsewhere when
locking isn't available (as it isn't in the SNMP case).
IE, under your new approach:
# opens table1, leaves the handle open and memorizes the returned data
update table1 set a = "b" where c = "d"
#
# ...
#
# If somewhere else someone did a "insert into table1(a,c)
# values("test","e") then the following update call will fail to
# update the new row in the next call below because the data memorized
# above would now be out of date.
#
# ...
#
update table1 set a = "b" where c = "e"
In the end, you're battling between what is best for the module
writers and what is best for the users. I'd suggest concentrating on
enable as many features as possible, but allow them to be disabled
from the module implementation when not possible. Meaning, the module
writer should be able to dictate whether tables can be left open or
should be reopened.
--
Wes Hardaker
NAI Labs
Network Associates
