Details

    • Type: Improvement
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.7.0SDK
    • Component/s: Core Java Framework
    • Labels:
      None

      Description

      Both users and the UIMA framework (during deserialization of CASes in XCAS, XMI, or various Binary formats) may want to modify a feature in a FS which is used as a key in some index specification. If this FS is in the index, then indices which use this feature as a key may become corrupted, unless the FS is first removed from the indices. After that, the feature may be updated, and the FS re-added to the indices.

      If allow_multiple_add_to_indices is enabled, a particular FS may be added to indices multiple times; the above remove operation would need to remove all of these, and the above add operation would need to add-to-indices the same number as was removed.

      The count of the number of times a FS was in the indices needs to be kept by View.

      There are several optimizations possible for this operation. Bag indices do not need to be disturbed as they have no keys. Set indices only have at most one instance of a particular FS. FSs which are subtypes of AnnotationBase are only indexed in at most 1 view (the view of their sofa). The remove-all kind of operation for Sorted indices can be made efficient in that all the identical elements are stored adjacently, and the remove can be done in bulk.

      The update operations for one FS may involve multiple key values.
      Design a way to encapsulate the update operation that is efficient, for both users and the UIMA framework, supporting both a try-finally approach and an encapsulation via a Runnable.

      For example, for try - finally:

      AutoCloseable ac = cas.protectIndices();
      try {
           ... user code ...
      } finally {
         ac.close();
      }
      

      or, with a Runnable (written in Java 8 lambda style):

      cas.withProtectIndices( () -> {
          ... user code ...
      });
      

        Issue Links

          Activity

          There are no comments yet on this issue.

            People

            • Assignee:
              schor Marshall Schor
              Reporter:
              schor Marshall Schor
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development