[
https://issues.apache.org/jira/browse/JCR-1892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12662918#action_12662918
]
Thomas Mueller commented on JCR-1892:
-------------------------------------
What about
"The identifier is opaque, meaning it can have any format and size, however
it is at normally about 50 characters and at most 255 characters long.
The string only contains Unicode code points from 32 to 127 (including)."
For some databases, the VARCHAR limit is 255. Unicode code points 32 to 127 are
the same in ASCII, and I don't like to exclude ':' and '/' to support URLs; and
I don't like to exclude base64 encoding.
> If you already have a DataIdentifier for something, then it's highly likely
> that the corresponding record also exists in the DataStore
One use case is fast data migration (from one repository to another). In that
case the record usually doesn't exist yet.
I don't see any harm in getRecordIfStored().
> Unique ID for org.apache.jackrabbit.value.BinaryValue
> -----------------------------------------------------
>
> Key: JCR-1892
> URL: https://issues.apache.org/jira/browse/JCR-1892
> Project: Jackrabbit
> Issue Type: New Feature
> Components: jackrabbit-jcr-commons
> Reporter: Thomas Mueller
> Assignee: Thomas Mueller
> Attachments: JackrabbitValue-api.patch, JackrabbitValue-core.patch
>
>
> BinaryValue should have a method get the unique identifier (if one is
> available). That way an application may not have to read the stream if that
> value is already processed.
> When the DataStore is used, a unique identifier is available, so probably
> this feature is quite simple to implement.
> See also http://www.nabble.com/Workspace.copy()-Question-...-td20435164.html
> (but please don't reply to this thread from now on - instead add comments to
> this issue).
> Another feature is getFileName() to get the file name if it is stored in the
> file system. This method may need a security mechanism, for example
> getFileName(Session s) so that the system can check it. In any case the file
> should not be modified, but maybe knowing the file name is already too
> dangerous in some cases.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
