[jira] [Created] (UIMA-4433) UIMA Sets have contradictory aspect - document this

["Marshall Schor (JIRA)" <de...@uima.apache.org>]

Marshall Schor created UIMA-4433:
------------------------------------

             Summary: 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
            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)