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

angela commented on OAK-597:
----------------------------

yes, i originally introduced such a unique property validator and added an 
unfinished implementation for
jcr:uuid and the unique user properties... it got removed (and replace by 
unique indexes) at revision 1381300

see http://markmail.org/message/7zorbiw25a3xoe4v

one thing that i didn't know how to solve while playing around with it at that 
time: 

how was it possible to search for existing properties that would expose the 
violation? 
the commit hooks are associated with the node store while the query engine 
currently requires the 
Root and the index providers and thus cannot be created with the validator 
provider (or some other commit hook)...

in addition it would be required to make sure that a single change set doesn't 
violate the uniqueness
constraints (would not be detected by the query on the persisted data).

                
> Uniqueness validator instead of unique index
> --------------------------------------------
>
>                 Key: OAK-597
>                 URL: https://issues.apache.org/jira/browse/OAK-597
>             Project: Jackrabbit Oak
>          Issue Type: Improvement
>          Components: core, query
>            Reporter: Thomas Mueller
>            Priority: Minor
>
> We currently have a few unique indexes that ensure only one node may exist 
> for a given node type / property name / property value combination (for 
> example the jcr:uuid needs to be unique).
> While this works, I see some problems with this approach:
> - Indexes might be removed by an admin or they might not be available due to 
> misconfiguration.
> - It (slightly) complicates the index implementation.
> - The index needs to do something that is not obvious (the index has to act 
> like a constraint / validator). Updating an index can fail for different 
> reasons that have a different meaning: updating the index might fail due to 
> duplicate key (which is not recoverable), and it might fail due to a conflict 
> (which is recoverable).
> Instead of using unique indexes, I propose to use a validator instead. The 
> validator can internally run a query to check if such a value already exists.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to