Jeff Zucker wrote:
> For both speed and data-security reasons, I would like to offer an
> alternative mode of operation for SQL::Statement that behaves more like
> the AnyData tied-hash interface in which a) files remain open and
> flocked until they are specifically closed by the user or the variable
> holding them goes out of scope and
No problem I can see here.
b) deletions are performed by adding
> a record's tell() into a hash and only physically performed when the
> file is closed. This means that the unocking and the
> truncating-rewriting only happens once for each file regardless of how
> many operations are performed.
That's *very* dangerous. I would not do that, in particular
because you have to care about the size of the deleted record.
You should consider that performance is not so much an issue
for a CSV module. Whoever actually needs performance, should
definitely not use a CSV database.
IMO a better strategy would be to write a DBM-Module for AnyData
and use that, if someone really needs performance. Using MySQL
would be even better, of course.
> A side benefit of this approach will be that SQL::Statement will be able
> to send updated rows as single rows, not as an entire array of all rows
> which will be of great benefit to things like the AnyData::Format::SNMP
> that Wes Hardaker is finalizing.
I do not know about this module. IMO SQL::Statement (at least the
classic module) puts no restrictions like that.
