[ 
https://issues.apache.org/jira/browse/OAK-5253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15741338#comment-15741338
 ] 

Julian Sedding commented on OAK-5253:
-------------------------------------

[~amitjain] In {{BlobStoreBlob#equals}} there is the following comment before 
comparing blob ids (and that's the best I could find regarding the guarantees 
of blob ids).

{quote}
// theoretically, the data could be the same  
// even if the id is different
return b.blobId.equals(blobId);
{quote}

So strictly speaking, just like with {{#getContentIdentity()}}, equal blob ids 
guarantee that two blobs are equal, but different blob ids do not guarantee 
that two blobs are different.

I don't want to be a pain, and since {{BlobStoreBlob}} already uses the blob 
ids to implement equals, I won't object here. However, I would prefer if we 
could extend or clarify the contract of {{BlobStore}} or {{Blob}} in order to 
accommodate the use-case of determining that two blobs are different without 
comparing their bytes.

> Optimize AbstractBlob#equal to not do content equals when possible
> ------------------------------------------------------------------
>
>                 Key: OAK-5253
>                 URL: https://issues.apache.org/jira/browse/OAK-5253
>             Project: Jackrabbit Oak
>          Issue Type: Improvement
>          Components: blob
>            Reporter: Amit Jain
>            Assignee: Amit Jain
>             Fix For: 1.6, 1.5.16, 1.4.11
>
>         Attachments: OAK-5253.1.patch
>
>
> AbstractBlob#equals tries to match content when length is equal and content 
> identities is not null and different. Matching content triggers an expensive 
> download of binaries for S3DataStore.
> Since, right now the content identity is the content hash the check can be 
> short -circuited when the content identities is not null and not equal to 
> return false.
> This can be revisited if we change the identity to something different.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to