[jira] [Commented] (UIMA-4059) Checking for incorrect key modifications

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

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

Marshall Schor commented on UIMA-4059:
--------------------------------------

This has evolved with the realization that the Framework ought to support protecting indices, since the remove / addback operation is potentially complex, and optimizable.  Complex: the remove must be over all views where the item may be indexed; the remove can exclude bag indices (because they have no keys), and if allow-multiple-add-to-indices are allowed, a count needs to be maintained when removing and used when adding back (and multiple removes need to happen, until all identical instances are removed). optimizable - the remove only needs to be done if the FS is in the index, and we can cache the fact it's not in the index which covers the most common cases; and the remove and add can skip bag indices.

Support for this is in UIMA-4135.  Instead of throwing exceptions, the check would be better if it operated in "automatic" mode - where it automatically does the right remove/addback operation, and (optionally) gives a report.

This design would have the following modes:

1) high performance - no runtime-checks for corruption, as was the case prior to 2.7.0.   But the user could implement protectIndices blocks or try-finally blocks to do the optimized remove/addbacks.

2) automatic, with or without reporting.  This would replace the earlier design of this Jira, so instead of throwing an exception, it would report a Warning, and then proceed to automatically "handle" it.  Users not concerned with high performance could run with this mode without reporting.  Users concerned with high performance would get the report, implement their own "fixes" to the reported issues (including implementing protectIndices blocks / try - finally blocks around the reported spots), and then, run in #1 high performance mode.

Users running with automatic and with their own protectIndices blocks or try-finally blocks might be "rechecking" their pipeline to see if other things have crept in.  To make this work, automatic would be "turned off" within a protected area.  

> Checking for incorrect key modifications
> ----------------------------------------
>
>                 Key: UIMA-4059
>                 URL: https://issues.apache.org/jira/browse/UIMA-4059
>             Project: UIMA
>          Issue Type: Improvement
>          Components: Core Java Framework
>            Reporter: Marshall Schor
>            Assignee: Marshall Schor
>            Priority: Minor
>             Fix For: 2.7.0SDK
>
>
> Address the issue raised in Jira UIMA-4049, as follows: Add an optional check that checks, for every set of a Feature value, whether or not that Feature is used as a key in any Sort or Set index, and if so, if the Feature Structure is currently in any index in any View; if so, an exception is thrown.  
> This additional check is normally disabled, but can be enabled by specifying the JVM property {{-Duima.check_fs_update_corrupts_index}}.



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