[
https://issues.apache.org/jira/browse/UIMA-4433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marshall Schor resolved UIMA-4433.
----------------------------------
Resolution: Fixed
Assignee: Marshall Schor
> UIMA Sets have contradictory aspect - document this
> ---------------------------------------------------
>
> Key: UIMA-4433
> URL: https://issues.apache.org/jira/browse/UIMA-4433
> Project: UIMA
> Issue Type: Bug
> Components: Core Java Framework
> Reporter: Marshall Schor
> Assignee: Marshall Schor
> Priority: Minor
> Fix For: 2.7.1SDK
>
>
> While examining the CasObj implementation, I was surprised to notice that the
> comparator for Set indexes *always* included a "types-are-the-same". I
> looked at the test case for this, and saw some contradictory things.
> 1) You can ask an index to compare (using its defined comparator) two feature
> structures.
> 1a) If you define an index to compare feature A, and you make two instances
> of a Feature Structure with the same A value, but one is a subtype of the
> other, the myIndex.compare(fs1, fs2) will return 0 (indicating they are
> "equal" for the purposes of the comparator.
> 1b) If you define the comparator to compare feature A and use type
> priorities, then the compare will not be 0 (because the types are different).
> 2) back to the first comparator - just on feature A. If you add-to-indexes
> the two FSs, the 2nd one, even though it "compares" equal to the first using
> the index's comparator, will still be added to the indexes; the size() of the
> index will be 2, not 1.
> This is long-standing behavior, so I'm reluctant to change it. It is caused
> by a detail of the underlying implementation, where the index is actually
> kept as "n" separate indexes, by type, so the Type and the SubType are in two
> separate indexes.
> My feeling at this point is to update the documentation to correspond to this
> detail of the implementation. Other thoughts?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
