Skip to content
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

Open
wants to merge 13 commits into
base: trunk
Choose a base branch
from

Conversation

reschke
Copy link
Contributor

@reschke reschke commented Aug 2, 2024

No description provided.

@reschke reschke marked this pull request as draft August 2, 2024 10:24
@reschke reschke requested review from kwin, mbaedke and stefan-egli August 2, 2024 10:24
* specification, but to observe the actual behavior of the implementation
* (which may be hard to change).
*/
public class ImportOperationsTest extends AbstractRepositoryTest {
Copy link
Member

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.

Copy link
Member

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.

Copy link
Contributor Author

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.

session.save();
fail("Setting jcr:uuid after adding mixin:referenceable should fail");
} catch (ConstraintViolationException ex) {
// expected
Copy link
Member

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)

Copy link
Contributor Author

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 {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

JCR TCK?

Copy link
Contributor Author

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.

@stefan-egli
Copy link
Contributor

Just to mention one further, somewhat brutal, option : Equivalent to temporarily removing the mix:referenceable (with the goal to allow changing the jcr:uuid) would be to temporarily change the primaryType to an unprotected one that would allow changing the jcr:uuid. That could be achieved either by using a hard-coded raw type (eg nt:unstructured, oak:Unstructured depending on orderable or not) - or by temporarily adding an node type that extends the existing one, and in the temporary one make jcr:uuid not protected, eg:

            NodeTypeTemplate unprotectedNTT = ntMgr.createNodeTypeTemplate();
            unprotectedNTT.setName(tmpNodeTypeName);
            unprotectedNTT.setDeclaredSuperTypeNames(new String[] {primaryType.getName()});
            PropertyDefinitionTemplate pdt = ntMgr.createPropertyDefinitionTemplate();
            pdt.setName("jcr:uuid");
            pdt.setProtected(false);
            unprotectedNTT.getPropertyDefinitionTemplates().add(pdt);
            session.getWorkspace().getNodeTypeManager().registerNodeType(unprotectedNTT, true);
            target.setPrimaryType(unprotectedNTT.getName());
            target.setProperty("jcr:uuid", newUUID);
            target.setPrimaryType(primaryType.getName());
            session.getWorkspace().getNodeTypeManager().unregisterNodeType(unprotectedNTT.getName());
            session.save();

@reschke
Copy link
Contributor Author

reschke commented Aug 5, 2024

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...

@stefan-egli
Copy link
Contributor

unprotecting does work - I tested with the snipped added previously - it's just a bit ... brutal

@reschke reschke marked this pull request as ready for review August 7, 2024 14:00
@reschke reschke requested a review from kwin August 7, 2024 14:00
// 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.
Copy link
Contributor

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?

Copy link
Contributor Author

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);
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants