setMixins fails with referenced nodes

[danrot]

I have a node type called sulu:page, which inherits from the mix:referenceable node type. I have a node which has the mix:referencebale node type and is already referenced by some other nodes.

Now I would like to change the node to only have the sulu:page mixins and not the mix:referenceable mixin. So I call $node->setMixins(['sulu:page']), but when saving the data in the session to jackrabbit I get an error message like this:

{http://www.jcp.org/jcr/mix/1.0}referenceable can not be removed: the node is being referenced through at least one property of type REFERENCE

I have checked the curl request which is being sent, and there are two relevant parts, which I'll show in the following snippet:

--716fd5cc8a3f81528673d2a9af259887
Content-Disposition: form-data; name="/cmf/microlife/contents/a/jcr:mixinTypes"
Content-Type: jcr-value/name; charset=UTF-8
Content-Transfer-Encoding: 8bit

sulu:page

Some more data, and quite at the bottom I see a line like this:

^/cmf/microlife/contents/a/jcr:mixinTypes : []

It looks to me like it is resetting the mixinTypes before setting the new value, which causes some references to break.

Is there any reason this is built like that? Can we fix that? If I get a hint I would create a PR.

[dbu]

that looks wrong, the mixinTypes should be your new mixin, not an empty list. do you get another mixin change for your node that sets it to sulu:page?

i'd look at the transport part where it builds those instructions to see when it builds the mixin changes and try to figure out why it does not directly put the new mixin into that instrucation.

[danrot]

These are the two changes I get. I have checked out the Node class, and saw that it is uses the addMixin and removeMixin function. Might this be the cause of this error? I thought removes are handled first by the transport layers, so that this error would make sense. And the doctrine dbal implementation probably is just not as strict with checking this kind of stuff.

[dbu]

dbal basically does not check such things, its a lot more sloppy.

its possible that we record the remove and add as separate operations. the tricky bit is probably when stuff moves around in between and whatnot. in this case at least it would be possible to aggregate the two things into one instruction. not sure if thats possible in general however, or if it could lead to new issues. can you check if it could be possible to aggregate multivalue property changes into one change? is there any risk of messing up, could move operations come in between, or other things that set properties?

[danrot]

I'll try to have a look next week.

[danrot]

Ok, I have tried a bit, and managed it to get jackalope-jackrabbit sent the following body in the request (nothing I could commit, probably breaks a 100 other cases):

--e5ed4ec33b61cf9a7617a0a7355714b8
Content-Disposition: form-data; name="/cmf/sulu_io/contents/test/i18n:en-changed"
Content-Type: jcr-value/date; charset=UTF-8
Content-Transfer-Encoding: 8bit

2016-11-18T09:15:50.000+00:00
--e5ed4ec33b61cf9a7617a0a7355714b8
Content-Disposition: form-data; name="/cmf/sulu_io/contents/test/i18n:en-published"
Content-Type: jcr-value/date; charset=UTF-8
Content-Transfer-Encoding: 8bit

2016-11-18T09:15:50.000+00:00
--e5ed4ec33b61cf9a7617a0a7355714b8
Content-Disposition: form-data; name=":diff"
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

^/cmf/sulu_io/contents/test/i18n:en-links : []
^/cmf/sulu_io/contents/test/i18n:en-changed : 
^/cmf/sulu_io/contents/test/i18n:en-state : 2
^/cmf/sulu_io/contents/test/jcr:mixinTypes : ["sulu:page"]
^/cmf/sulu_io/contents/test/i18n:en-published : 
--e5ed4ec33b61cf9a7617a0a7355714b8--

So it only sets the mixin types directly, but it still throws the same error:

{http://sulu.io/phpcr}page can not be removed: the node is being referenced through at least one property of type REFERENCE

So it looks to me like this is an issue in jackrabbit, right?

[danrot]

Although in this example the node already has the type sulu:page, it looks like as soon as somebody touches jcr:mixinTypes, it will remove and readd them again internally, causing that error 😕

[dbu]

have you been able to reproduce this with the java jackrabbit remoting? or does that send the information differently?

[danrot]

The following behavior occured to me when testing this using java -jar jackrabbit-standalone-2.12.3.jar --cli http://localhost:8080/server:

There is a node with the mix:referencable mixin being referenced somewhere else.

If I execute removemixin mix:referenceable it immediately fails as expected:

exception: javax.jcr.nodetype.ConstraintViolationException
message: Mixin type mix:referenceable can not be removed: the node is being referenced through at least one property of type REFERENCE

If I executed addmixin sulu:page (which again includes the mix:referenceable) and execute removemixin mix:referenceable it works so far, but breaks when I execute the save command with the same message as above.

[dbu]

@danrot did you find a solution for this? do we have a problem with the order of operations for this one? looks like we send operations in the wrong order. does it work if you save the session between the two operations?

[danrot]

I didn't find any time to dig into this deeper...But as written above, it doesn't only seem to be about the wrong order, even if I fix the command sent via the API to jackrabbit it fails. Haven't tested saving the session between the addmixin and removemixin option, but that wouldn't be an acceptable solution in my case anyway.