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
remove dependency on fcrepo-mint #856
Conversation
This replicates the current behavior, but there's also an outstanding ticket for making the event ids configurable: https://jira.duraspace.org/browse/FCREPO-1568 Can we inject a Supplier, allowing us to wire up whatever kind of ID minter was desired? This would also remove the dependency on fcrepo-mint. |
@escowles How do you want to use a |
@ajs6f I think it's stripping out the angle brackets: I meant to say Supplier<String> -- so a supplier of ids. I think it makes sense to use the same approach we're using for the main repository ids in https://github.com/fcrepo4/fcrepo4/blob/master/fcrepo-http-commons/src/main/java/org/fcrepo/http/commons/AbstractResource.java#L101 |
Holy crap! That's no good. |
So maybe we should add a PidMinter interface to fcrepo-kernel-api, and then inject fcrepo-mint instances in the fcrepo-http-commons repository config? |
I don't think we should be as specific as |
|
Hey, man, this is Java 8! The UUID impl becomes default method bodies on the interface itself. |
@@ -64,7 +61,7 @@ | |||
*/ | |||
public FedoraEvent(final Event e) { | |||
checkArgument(e != null, "null cannot support a FedoraEvent!"); | |||
eventID = pidMinter.get(); | |||
eventID = randomUUID().toString(); |
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.
Instead of hard-coding randomUUID()
here, is there a reason why an UniqueValueSupplier<String>
, as suggested in the code review comments, was not injected?
As a note, randomUUID().toString()
is not equivalent to the previous UUIDPathMinter.get()
. UUIDPathMinter
provides a pairtree path with a UUID leaf element, whereas randomUUID
simply provides a UUID.
The reason a full pairtree path is important is because the InternalAuditor
uses the FedoraEvent#eventID
as the identifier name at which an audit record resource is created:
https://github.com/fcrepo4-labs/fcrepo-audit/blob/master/src/main/java/org/fcrepo/audit/InternalAuditor.java#L211
The pairtree path provided by the UUIDPathMinter
gets around the performance limitation of too many children of a given resource.
Updated PR with an injectable |
* @author awoods | ||
* @author acoburn | ||
*/ | ||
public interface UniqueValueSupplier extends Supplier<String> { |
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 way more specific than the name UniqueValueSupplier
would imply. How about HierarchicalIdentifierSupplier
< UniqueValueSupplier
, with UniqueValueSupplier
simply guaranteeing the uniqueness of results (no default impl) and HierarchicalIdentifierSupplier
bringing the "minter that creates hierarchical IDs from a UUID" semantic with the default impl?
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.
That works for me. I can add the additional interface.
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.
Right on.
added an interface for |
import java.util.function.Supplier; | ||
|
||
/** | ||
* Unique value minter that creates unique IDs |
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 now the wrong comment. This type just guarantees the uniqueness of its supplied values. It has nothing to do with minting IDs.
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 comment has been updated.
This looks good. @escowles, you will note that the issue of injecting a If @escowles or @ajs6f are comfortable with this current PR as well, I will go ahead and squash/merge. |
👍 -- looks like a good improvement, and we can figure out the injection separately. |
@@ -54,8 +54,7 @@ | |||
|
|||
private Set<Integer> eventTypes = new HashSet<>(); | |||
private Set<String> eventProperties = new HashSet<>(); | |||
|
|||
private static final Supplier<String> pidMinter = new UUIDPathMinter(); | |||
private UniqueValueSupplier pidMinter = new DefaultPathMinter(); |
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.
shouldn't this be static final
?
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.
yes
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 you push one more commit with the addition of static
we can close this PR.
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.
Commit pushed (actually two). The nested classes had to be made static in order to use them on a static field.
Resolved with: f7daf30 |
See: https://jira.duraspace.org/browse/FCREPO-1642