-
Notifications
You must be signed in to change notification settings - Fork 414
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
OAK-11000: Test coverage for common JCR operations related to importing content #1622
base: trunk
Are you sure you want to change the base?
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If it's there we could drop it.
} | ||
|
||
@Test | ||
public void jcrMixinReferenceableOnNtUnstructuredAfterRemovingMixinButDanglingReference() throws RepositoryException { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
JCR TCK?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.