Re: [xml-dev] Update-order of XQuery Update Facility

["Johannes.Lichtenberger" <Johannes.Lichtenberger@uni-konstanz.de>]

On 08/30/2012 07:00 PM, Michael Kay wrote:
> On 15/08/2012 07:19, Johannes.Lichtenberger wrote:
>> I've seen some XQuery Update Facility implementations on top of
>> DOM-like tree-structures which for instance prohibit two attributes
>> with the same QName and the same target element-node. In our case we
>> (or I ;-)) set a new attribute-value if the QNames are identical but
>> the values differ. This is to provide a DOM-like Java-API on the
>> tree-structure and to apply updates on the fly (but obviously
>> persisted only once the transaction is commited).
> The spec is clear here that at the point all the pending updates are
> applied, it's an error if applying all the updates results in two
> attributes of an element having the same name.

Yes, I think I wasn't clear about this, but I'd like to provide 
immediate consistency, to implement the XQuery Update Facility on top of 
our usual Java API which for instance doesn't allow to insert attributes 
with an identical QName at any time, because the operation is 
immediately reflected in the tree-structure however not visible to 
concurrent reading transactions and just in memory (or in the 
transaction write-ahead log) until the transaction is commited.

>> However, both approaches fail for instance in the following case:
>>
>>   insert node attribute {"foo"} {"baz"} into /root,
>>   delete node /root/@foo
>>
>> with a simple document like this:
>>
>> <root foo="bar">
>>
>> it temporally yields two attributes with the same QName, however
>> foo="bar" is deleted afterwards which yields <root foo="baz">.
> The spec is clear that this is allowed. Even though inserts are done
> before deletes, temporary inconsistencies are allowed; it's only if the
> final result after applying all the updates is inconsistent that a
> dynamic error occurs.

I'm currently investigating how to implement the spec without causing 
inconsistencies at any time. That is why I think deleting attributes can 
be done before inserting attributes.

>> But on the downside adjacent text-nodes are also merged on the fly
>> which introduces side-effects (for instance once inserting a new
>> right-sibling text node of a text node which is merged with the left
>> one and a subsequent deletion of the old text node). Maybe in our case
>> we have to search for such cases beforehand and apply these deletions
>> at first (or simply apply all deletions at first, which obviously also
>> results in another, most probably unexpected update behavior ;-)).
>>
> Again, I think the spec is quite clear on the outcome. You do all the
> inserts and deletes, then you merge adjacent text nodes.
>
> How you implement it is another matter - that's up to you.

I think this case is much harder, if we immediately trigger an insert 
once the PUL should be applied. That is, I've changed our text insertion 
methods to append or prepend text to the node which is already persisted 
if it would yield adjacent text nodes instead. However it is not 
consistent with the spec if someone wants to insert a right sibling text 
node to a text node and afterwards delete the original text node.

Currently in our case the new right sibling text node would not have 
been created and the String-value would have been appended to the "left" 
text node, thus the update would have been lost after deleting the 
original "left" text node in a subsequent step.

Well, maybe it is ok to rewrite this case to a single setText(String) 
method on the original text node.

But maybe we can also introduce some kind of eventual consistency 
(checking for consistency at commit-time) which can be enabled for 
instance for the XQuery Update Facility implementation.

kind regards,
Johannes