Hi,
On 4/13/07, Marcel Reutegger <[EMAIL PROTECTED]> wrote:
Jukka Zitting wrote:
> In fact most of that could already be achieved by a Batch
> implementation that is backed by the draft revision. The main problem
> at the moment is that the client still needs to keep a full copy of
> everything it passes to the Batch in order to properly support reading
> transient changes. Would it be possible to add getter methods to the
> Batch interface?
a batch is distinct from transient changes because it potentially is only a
subset of the transient changes (when save is called on an item that is not the
root node and the workspace has changes not just below that item). as a
consequence a batch is only created when save is called. whether a 'full copy'
is required depends on the SPI implementation. it is also possible to interpret
the client-side calls on the batch directly into server-side calls of the native
store. in that case no copies are created except whatever is required/needed in
the native storage.
The copies I'm concerned about are created when a client wants to read
a property that has not yet been persisted. For example if I want to
do a large XML import and postprocess it before persisting all the
changes. The "draft revision" model would nicely support such a use
case without excessive memory requirements or having to make another
copy of the subtree when saving it.
counter question: would it be possible to create a draft revision that is
immediately persisted?
Certainly, but see the concerns above. Doing that loses some of the
nice session management features outlined in the proposal.
I'd rather not create objects in the core or the server that are long lived and
potentially not used because a client decides to discard a draft revision.
A draft revision that gets discarded would just get removed from the
disk, so I don't think this is a problem.
BR,
Jukka Zitting
