Non-rdf resources emit /fcr:metadata events instead of /jcr:content #582
Conversation
| message.setStringProperty(IDENTIFIER_HEADER_NAME, jcrEvent.getPath()); | ||
| String path = jcrEvent.getPath(); | ||
| if ( path.endsWith("jcr:content") ) { | ||
| path = path.replaceAll("jcr:content","fcr:metadata"); |
There was a problem hiding this comment.
Pretty sure we have constants for these.
Do you really want to emit the event for the binary description, or can we just emit it for the binary and make the client figure it out (e.g. by doing a HEAD request on the target)?
There was a problem hiding this comment.
+1 : use constants (FedoraJcrTypes.FCR_METADATA, plus maybe an addition for JCR_CONTENT in RdfLexicon).
My expectation would be that:
- updates to binaries would send events with the binary path, and
- updates to binary descriptions would send events with the path to /fcr:metadata.
Is that a shared expectation?
There was a problem hiding this comment.
JCR_CONTENT is available as a constant from MODE.
There was a problem hiding this comment.
I'll swap in the JCR_CONTENT and FCR_METADATA constants.
I'm not sure precisely what the current behavior is, other than to say that the message consumer expects the event to point to RDF instead of the binary, which is why I was updating the jcr:content events to point to fcr:metadata instead of to the binary itself.
There was a problem hiding this comment.
For non-RDF resource /path/to/resource
- updating the content => event on /path/to/resource/fcr:content
- updating the description => event on /path/to/resource
IMHO, both of them should be mapped to /path/to/resource/fcr:metadata, since that is the description for both of them that the message consumer can work with. If it wants the content (e.g. for fulltext indexing, etc.), then the fcr:metadata will have a pointer to it.
| message.setStringProperty(IDENTIFIER_HEADER_NAME, jcrEvent.getPath()); | ||
| String path = jcrEvent.getPath(); | ||
| if ( path.endsWith("/" + JCR_CONTENT) ) { | ||
| path = path.replaceAll("/" + JCR_CONTENT,""); |
There was a problem hiding this comment.
On binary update events, you appear to be sending a message with the binary path.
In the case where the event is on the description (i.e. /fcr:metadata) the message is with the description path.
This does not seem to be in line with your previous comments in this thread:
#582 (comment)
There was a problem hiding this comment.
@awoods Not exactly. With an update on the binary, the event path is /path/to/resource/fcr:content -- I'm removing the /fcr:content to make the event path the resource path. When the event is on the description, the path is already the resource path, so I'm leaving it unchanged. So in both cases, the end result is that the event is emitted with the resource path.
|
Resolved with: f388cd7 |
Fixes https://www.pivotaltracker.com/story/show/81279166