Conversation
…ng content (work-in-progress)
…ng content (work-in-progress)
| * specification, but to observe the actual behavior of the implementation | ||
| * (which may be hard to change). | ||
| */ | ||
| public class ImportOperationsTest extends AbstractRepositoryTest { |
There was a problem hiding this comment.
The class name is confusing to me. What about ProtectedPropertyTest because IIUC this is mainly about jcr:uuid and jcr:created for cases when both become protected.
There was a problem hiding this comment.
Maybe even split up general protected properties from jcr:uuid into dedicated test classes make sense because the latter imposes additional restrictions.
There was a problem hiding this comment.
Done the remaining; let's discuss splitting later on.
oak-jcr/src/test/java/org/apache/jackrabbit/oak/jcr/ImportOperationsTest.java
Outdated
Show resolved
Hide resolved
oak-jcr/src/test/java/org/apache/jackrabbit/oak/jcr/ImportOperationsTest.java
Outdated
Show resolved
Hide resolved
| session.save(); | ||
| fail("Setting jcr:uuid after adding mixin:referenceable should fail"); | ||
| } catch (ConstraintViolationException ex) { | ||
| // expected |
There was a problem hiding this comment.
This is IMHO mandated by the JCR spec as mix:referenceable defines jcr:uuid as protected (so this test rather belongs to the JCR TCK)
There was a problem hiding this comment.
If it's there we could drop it.
| } | ||
|
|
||
| @Test | ||
| public void jcrMixinReferenceableOnNtUnstructuredAfterRemovingMixinButDanglingReference() throws RepositoryException { |
There was a problem hiding this comment.
Maybe; if you can find it. For now I'll leave it here, because having related tests in different places doesn't seem to be helpful.
…erited (such as from nt:resource)
… when another referenceable node already has that UUID
|
Just to mention one further, somewhat brutal, option : Equivalent to temporarily removing the |
|
The first two options would be problematic if the parent node requires a certain type (ack @kwin :-). The latter would work if extending a type would indeed allow "unprotecting" a property... |
|
unprotecting does work - I tested with the snipped added previously - it's just a bit ... brutal |
…tured (ack mbaedke)
…ed jcr:uuid (ack stefan-egli), also minor refactoring
| // JCR spec | ||
| // (https://developer.adobe.com/experience-manager/reference-materials/spec/jcr/2.0/3_Repository_Model.html#3.8%20Referenceable%20Nodes) | ||
| // requests an "auto-created" property, so it might be a surprise | ||
| // that Oak actually keeps the application-assigned previous value. |
There was a problem hiding this comment.
The algorithm used to create the property value is free to use the existing one and I think that is also the most sane approach, so is it really that surprising?
There was a problem hiding this comment.
the spec says "autocreated" :-)
| Node test = testNode.addNode(TEST_NODE_NAME, NodeType.NT_UNSTRUCTURED); | ||
| test.addMixin(NodeType.MIX_REFERENCEABLE); | ||
| session.save(); | ||
| Node ref = testNode.addNode(TEST_NODE_NAME_REF, NodeType.NT_UNSTRUCTURED); |
There was a problem hiding this comment.
Nitpick: Earlier the name ref was used for the referenced node, not the referencing one. So we might want to change that to avoid confusion.
No description provided.