Wrong JNUP0006 error?

[wcandillon]

The following query raises an error: http://try.zorba.io/queries/xquery/HdaN8mUvpAIlifs1CgBmz8gZhQo%3D It is not clear from reading the specification that this error should happen?

[wcandillon]

I could be wrong but this seems inconsistent with the same version of the query with xml nodes: http://try.zorba.io/queries/xquery/qh37HplV0puYbEZZDLfSPBrJxuk%3D

[MatthiasBrantner]

Isn’t this about the insertion of a pair with the same name? This cannot happen with XML.

On Aug 9, 2014, at 12:20 PM, William Candillon notifications@github.com wrote:

I could be wrong but this seems inconsistent with the same version of the query with xml nodes: http://try.zorba.io/queries/xquery/qh37HplV0puYbEZZDLfSPBrJxuk%3D

— Reply to this email directly or view it on GitHub.

[wcandillon]

Correct, the following two queries behave consistently: http://try.zorba.io/queries/xquery/QOgL%2Foy3DJthSP41EUKNi7Z9uw4%3D http://try.zorba.io/queries/xquery/ggGUhCUEuOUaVmfxjTOJ4ygDdas=

So the current behaviour of Zorba is correct? I guess that the spec makes it pretty clear actually: "Update primitives within a PUL are applied with strict snapshot semantics. For examples, the positions are resolved against the array before the updates. Names are resolved on the object before the updates."

"First, before applying any update, each update primitive (except the jupd:insert-into-object primitives, which do not have any target) locks onto its target by resolving the selector on the object or array it updates. "

[MatthiasBrantner]

So, I guess this really comes down to an implementation-dependent behavior. In the Zorba case, the error seems to be raised when the update primitive is created. This could be postponed to the apply phase. In this case, no error would be raised if the rename updates are executed before the insert. If the implementation would choose a different order, an error would be raised.

On Aug 9, 2014, at 12:31 PM, William Candillon notifications@github.com wrote:

Correct, the following two queries behave consistently: http://try.zorba.io/queries/xquery/QOgL%2Foy3DJthSP41EUKNi7Z9uw4%3D http://try.zorba.io/queries/xquery/ggGUhCUEuOUaVmfxjTOJ4ygDdas=

So the current behaviour of Zorba is correct? I guess that the spec makes it pretty clear actually: "Update primitives within a PUL are applied with strict snapshot semantics. For examples, the positions are resolved against the array before the updates. Names are resolved on the object before the updates."

"First, before applying any update, each update primitive (except the jupd:insert-into-object primitives, which do not have any target) locks onto its target by resolving the selector on the object or array it updates. "

— Reply to this email directly or view it on GitHub.

[ghislainfourny]

Hi Matthias,

Actually, this is not implementation-dependent and there is no order of application; in other words, it must be as if all updates were applied simultaneously (even though implementations may internally use an order as long as it does not alter semantics). No error should actually be raised. However, Zorba does not fully support JSONiq updates and throws errors in some corner cases. Ideally, it should be fixed at some point when time and resources permit.

Kind regards, Ghislain

[wcandillon]

Similarly, I would expect http://try.zorba.io/queries/xquery/qiYcSIkBJ8rs2UB%2B%2FeVWO935ePs%3D to return:

{ a: {} }

Which would be consistent with the behaviour of apply(insert-into-collection(i), delete-from-collection(i))

I hope I am not making mistakes in the reference results.