The build passes for me locally, so I restarted the Travis build and it passed.

But I also did some testing with limiting the pairtree to a single character to test collisions (see https://github.com/escowles/fcrepo4/commit/48d1aa5e7672e2f5b969dace4b2dc1ee745bdb78), and found that this PR makes any collision fail, even POSTing to /rest when it generates a collision.

I am also concerned about the implications of this PR for multiple applications using the repository. What if one app uses auto-generated IDs, but another app generates its own UUIDs and formats them to fit the same pairtree pattern? Should PUT requests to create objects that happen to be in the same terminal pairtree element fail? Why?

These can both be addressed by only preventing creation of nodes in non-terminal pairtree nodes.

The idea here is that pairtree nodes are an internal construct and should not be used by client applications as first-class resources.

Can you clarify what you mean by "These can both be addressed by only preventing creation of nodes in non-terminal pairtree nodes."? Specifically, what you mean by "non-terminal pairtree nodes".

In the example where a resource is created at: /rest/ab/cd/ef/gh/some-uuid
If the above resource where created by F4 or the client passing in the full path, then the intermediate nodes will be pairtrees, i.e. ab and cd and ef and gh are all pairtrees.
The implementation in this PR disallows the creation of the following, subsequent resource: /rest/ab/cd/ef/gh/foo

By "non-terminal pairtree nodes", are you suggesting that in the above scenario the creation of /rest/ab/cd/ef/gh/foo be allowed but /rest/ab/cd/ef/foo not? If so, the distinction is lost on me for how that helps.
As a note, the following, analogous ticket for POST is already in the codebase: https://jira.duraspace.org/browse/FCREPO-1505

Andrew-

I have two things in mind:

1. If a POST to /rest creates /ab/cd/ef/gh/abcdefgh1234, and a subsequent POST to /rest creates /ab/cd/ef/gh/abcdefgh4567, then the second POST should succeed. With a current master build it succeeds, but with this PR, it fails.
2. If a POST to /rest creates /ab/cd/ef/gh/abcdefgh1234, and another application creates its own identifer /ab/cd/ef/gh/abcdefghZZZ1, then that separate client should be able to create that path. Of course the application minting its own identifiers would need to take care to prevent collisions with existing (or potential future) repository-minted identifiers. But there are many ways to do that without preventing the use of the same hierarchy.

This ticket (https://jira.duraspace.org/browse/FCREPO-1627) is intended to prevent the case of directly PUTting to a pairtree resource. The implementation in this PR pushes that logic lower in the stack, which has the result of impacting a broader range of use cases. I would suggest we do one of two things:

1. Clearly define the full scope of scenarios where we expect resource creation operations to work and scenarios where we expect them to fail. OR
2. Move the logic of this PR higher in the stack to address the specific scenario of: PUT /pair/tree/new-resource

My PR looks like a mess, but this commit adds an IT based on my previous comment that currently fails:

https://github.com/escowles/fcrepo4/commit/fa260241ccaacdb042367804f2fd4d5f481e81ae

If we allow minting identifiers externally, and suggest using a pairtree for performance reasons, and auto-create intermediate nodes, then I think we should also allow creating new leaf nodes in those auto-created intermediate nodes.

I think I agree with @escowles . Why discriminate?

@escowles, do you have thoughts on this comment?
#901 (comment)

"1) Clearly define the full scope of scenarios where we expect resource creation operations to work and scenarios where we expect them to fail."

I think LDP does this pretty well already. We just need to add a few constraints related to our dumb "magic" URIs like fcr:metadata. I don't see that pairtreeness comes into it.

@awoods: I am very sympathetic to restricting POSTs. POSTing to a container seems well-understood, but POSTing to a pairtree node seems more likely to be a mistake, or to be intended to do something different from what Fedora will actually do.

On the other hand, I think restricting PUTs will break the ability to use external identifiers and auto-created intermediate nodes. If I want to create /a/b/c now, and might want to later create /a/b/x and /a/x/y, then I would have to create all the intermediate nodes myself.

So I'm open to discussing scenarios where we expect PUTs to be disallowed, but I am skeptical that there are any other than the fcr: namespaced endoints.

@escowles, thanks, that is helpful. If I understand you correctly, your suggestion is to simply disregard this PR and associated ticket?

Yes, my preference would be to close this PR and FCREPO-1627.

+1

I tested this and it works as expected.
POST generates a resource at
http://localhost:8080/rest/3d/5b/53/28/3d5b5328-ab8e-4e19-8308-b458b897e8f2

[...]

The build passes for me locally, so I restarted the Travis build and it passed.

Thank you @whikloj (by means of JIRA) and @escowles for testing this.

Further, my apologies for not undertaking the proper measures to discuss such architectural concerns with the community. That an identifier minting service could easily introduce conflicts into functionality which limits the creation and updates of resources under pairtree nodes is something which I obviously overlooked.

Yes, my preference would be to close this PR and FCREPO-1627.

+1

Decided to discard this PR.

Still, good work by @jrgriffiniii to get this issue clarified.

Thank you very much @ajs6f, I look forward to working to address whichever issues I can.