I think that I should probably implement SQL∆with_transaction. It belongs in the SQL layer. It's also the only way to ensure that transaction rollback on error is handled correctly.
Regards, Elias On 21 April 2014 12:18, David B. Lamkins <dlamk...@gmail.com> wrote: > One more code drop... > > I've factored out the encode and decode routines to make it easier to > experiment with the storage format. > > I've added a cf∆with_transaction operator to simplify transaction > support for applications that actually need it. This, I believe, is > useful since it lets the application determine policy for failed > transactions. > > I've extended the test cases and performance tests. > > One thing that's interesting is that cf∆append runs about twice as fast > inside the transaction wrapper than it does without. I imagine that > SQLite must be running several implicit transactions; these get deferred > by running the sequence of operations inside an explicit transaction. > > Despite that observation, I'm loathe to build-in transaction support for > the sake of speed. It'd help the case where component files are > implemented on SQLite, but might not be the right thing to do for other > databases. Again, this is a policy decision that belongs at a higher > level of abstraction. > >
