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.
counter question: would it be possible to create a draft revision that is immediately persisted?
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.
regards marcel
