Greg Stein wrote:
> I don't understand why transactions would be exposed to users of this
> API. Each API "should" leave the db in a consistent state. If each API
> does *not*, then you are placing a burden on the caller to make
> specific sets of calls in a specific order, which is usually hard to
> document, so you end up with unwritten assumptions.
Agreed, but I'm not yet sure of the level of modularity and consistency we want
or need in the working copy. SQLite performs much better with the use of
transactions, and using large transactions is a potential performance win for
people running on remote filesystems (think NFS). There is a balance to be
struck between one giant do-everything API and many individual
do-little-things-but-keep-the-wc-consistent API, and I'm not yet sure where that
should be.
> Optimizations around our use of SQLite should preferably be internal.
Sure. But should the notion of a transaction live outside the wc_db APIs?
Whether these are implemented as SQLite transactions or by loggy, we may need
some way of ensure macro consistency (though I'll admit to not having such a
scenario on hand).
Having written that, I just thought of the following question. Do we try and
keep things consistent on a client-api level ('svn ps -R' is an all or nothing
operations') or at the working copy level (each propset either succeeds or fails)?
> Is there something about your thinking which I'm missing?
Probably not. It's probably something about *your* thinking that I'm missing. :)
> Thanks,
> -g
>
> On Fri, Dec 19, 2008 at 13:28, Hyrum K. Wright <hyrum_at_hyrumwright.org> wrote:
>> Author: hwright
>> Date: Fri Dec 19 13:28:09 2008
>> New Revision: 34866
>>
>> Log:
>> WC-NG: Add a few more database administrative APIs. This mainly just fleshes
>> out some ideas I've had about transaction handling and general db
>> administration.
...
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=993878
Received on 2008-12-27 21:26:44 CET