You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@uima.apache.org by "Marshall Schor (JIRA)" <de...@uima.apache.org> on 2013/11/01 15:09:17 UTC
[jira] [Created] (UIMA-3399) More consistent handling of multiple
add-to-index behavior for same Feature Structure
Marshall Schor created UIMA-3399:
------------------------------------
Summary: More consistent handling of multiple add-to-index behavior for same Feature Structure
Key: UIMA-3399
URL: https://issues.apache.org/jira/browse/UIMA-3399
Project: UIMA
Issue Type: Brainstorming
Affects Versions: 2.4.2SDK
Reporter: Marshall Schor
Assignee: Marshall Schor
Priority: Minor
UIMA has a somewhat unusual indexing architecture. You can define indexes (sorted, bag, set), and then add / remove a feature structure (FS) to all of the defined indexes.
The design intention (I think) was to support the concept of a FS being indexed, or not. However, the current design allows some anomalies that behave inconsistently between code being run "locally", versus as remote services (due to how serialization handles this). Serialization encodes only the concept of a FS being either in an index or not.
The problem arises in the edge case where the same FS is added to the indexes multiple times. For local (non-remote) cases, for bag and sorted indexes, the same exact FS would be added multiple times. This would have the consequences:
- Iterating would return multiple == FSs.
- Remove from indexes of a multiply-added FS would reduce the number by 1; the FS would still be in the index.
For the same code, running remotely, serialization would have "collapsed" the multiple additions into one, so would behave differently.
A proposed improvement: Change the behavior of "add-to-index" so that subsequent add-to-indexes of a same FS would be either a no-op, or a delete / re-add (to cover the case where some feature values of the FS might have changed, and therefore leading to the need to re-index the FS). To cover users who might be exploiting the old behavior, we could have a framework context flag to re-instate the older behavior.
This would better align how code running locally or remotely works.
What do people think about this idea?
--
This message was sent by Atlassian JIRA
(v6.1#6144)
Re: [jira] [Created] (UIMA-3399) More consistent handling of multiple add-to-index behavior for same Feature Structure
Posted by Richard Eckart de Castilho <re...@apache.org>.
Let's see what the docs say.
The documentation says (http://uima.apache.org/d/uimaj-2.4.2/references.pdf):
> Adding Feature Structures to the Indexes
>
> Feature Structures are added to the indexes by calling the FSIndexRepository.addFS(FeatureStructure) method or the equivalent convenience method CAS.addFsToIndexes(FeatureStructure). This adds the Feature Structure to all indexes that are defined for the type of that FeatureStructure (or any of its supertypes). Note that you should not add a Feature Structure to the indexes until you have set values for all of the features that may be used as sort keys in an index.
>
> --
>
> public void addToIndexes()
>
> add the corresponding FeatureStructure to all Cas indexes
>
> --
>
> void addFsToIndexes(FeatureStructure fs)
>
> Add a feature structure to all appropriate indexes in the repository associated with this CAS View. If no indexes exist for the type of FS that you are adding, then a bag (unsorted) index will be automatically created.
>
> Important: after you have called addFsToIndexes(...) on a FS, do not change the values of any features used for indexing. If you do, the index will become corrupted and may be unusable. If you need to change an index feature value, first callremoveFsFromIndexes(...) on the FS, change the feature values, then call addFsToIndexes(...) again.
As far as I can tell, it is undefined what happens when an FS is added multiple times.
On the other hand, it is more-or-less defined what happens when the FS is removed:
> void removeFsFromIndexes(FeatureStructure fs)
>
> Remove a feature structure from all indexes in the repository associated with this CAS View.
I read that as: the FS should no longer be present in the indexes after this operation, no matter whether it has been added once or multiple times.
-- Richard
On 04.11.2013, at 15:08, Eddie Epstein <ea...@gmail.com> wrote:
> Consider a scenario where an annotator needs to remove
> an FS from the index repository. The only way to do this currently
> is to repeatedly remove FS from index until it is no longer there.
> Is that consistent or well documented?
>
> Do we know yet how much overhead Marshall is proposing?
>
> Eddie
>
>
>
> On Sat, Nov 2, 2013 at 7:25 AM, Thilo Goetz <tw...@gmx.de> wrote:
>
>> On 02.11.2013 11:33, Richard Eckart de Castilho wrote:
>>
>>> On 02.11.2013, at 11:17, Thilo Goetz <tw...@gmx.de> wrote:
>>>
>>> On 01.11.2013 22:13, Marshall Schor wrote:
>>>>
>>>>>
>>>>>
>>> <snip>
>>>
>>> I don't know of any cases where the same FS was *intentionally* added to
>>>>> the
>>>>> indexes multiple times; so I'm hoping (!) that changing this behavior
>>>>> won't
>>>>> break existing things.
>>>>>
>>>>
>>>> The why go to all this trouble to fix a non-existent issue?
>>>>
>>>
>>> The current behavior is inconsistent and apparently undesired. We could
>>> nail
>>> the behavior down to a desired state before somebody starts relying on
>>> it,
>>> and runs into problems, e.g. when mixing remote and local operations, or
>>> when
>>> moving from local to remote. I'd consider being forced to maintain
>>> inconsistencies
>>> as another maintenance nightmare.
>>>
>>> -- Richard
>>>
>>>
>> The current behavior of the local case is consistent, documented and
>> works as designed. I have still not heard an argument that would
>> convince me that adding the overhead Marshall is proposing to the
>> local implementation is in any way more desirable or easier than
>> to make the remote implementation consistent with the local one.
>>
>> --Thilo
Re: [jira] [Created] (UIMA-3399) More consistent handling of multiple
add-to-index behavior for same Feature Structure
Posted by Thilo Goetz <tw...@gmx.de>.
On 04.11.2013 15:08, Eddie Epstein wrote:
> Consider a scenario where an annotator needs to remove
> an FS from the index repository. The only way to do this currently
> is to repeatedly remove FS from index until it is no longer there.
> Is that consistent or well documented?
>
> Do we know yet how much overhead Marshall is proposing?
It is overhead, and it is completely unnecessary from where I'm
standing. That's all I need to know.
On the other hand, I really don't care any more. So please go
ahead, I won't argue.
>
> Eddie
>
>
>
> On Sat, Nov 2, 2013 at 7:25 AM, Thilo Goetz <tw...@gmx.de> wrote:
>
>> On 02.11.2013 11:33, Richard Eckart de Castilho wrote:
>>
>>> On 02.11.2013, at 11:17, Thilo Goetz <tw...@gmx.de> wrote:
>>>
>>> On 01.11.2013 22:13, Marshall Schor wrote:
>>>>
>>>>>
>>>>>
>>> <snip>
>>>
>>> I don't know of any cases where the same FS was *intentionally* added to
>>>>> the
>>>>> indexes multiple times; so I'm hoping (!) that changing this behavior
>>>>> won't
>>>>> break existing things.
>>>>>
>>>>
>>>> The why go to all this trouble to fix a non-existent issue?
>>>>
>>>
>>> The current behavior is inconsistent and apparently undesired. We could
>>> nail
>>> the behavior down to a desired state before somebody starts relying on
>>> it,
>>> and runs into problems, e.g. when mixing remote and local operations, or
>>> when
>>> moving from local to remote. I'd consider being forced to maintain
>>> inconsistencies
>>> as another maintenance nightmare.
>>>
>>> -- Richard
>>>
>>>
>> The current behavior of the local case is consistent, documented and
>> works as designed. I have still not heard an argument that would
>> convince me that adding the overhead Marshall is proposing to the
>> local implementation is in any way more desirable or easier than
>> to make the remote implementation consistent with the local one.
>>
>> --Thilo
>>
>>
>
Re: [jira] [Created] (UIMA-3399) More consistent handling of multiple
add-to-index behavior for same Feature Structure
Posted by Eddie Epstein <ea...@gmail.com>.
Consider a scenario where an annotator needs to remove
an FS from the index repository. The only way to do this currently
is to repeatedly remove FS from index until it is no longer there.
Is that consistent or well documented?
Do we know yet how much overhead Marshall is proposing?
Eddie
On Sat, Nov 2, 2013 at 7:25 AM, Thilo Goetz <tw...@gmx.de> wrote:
> On 02.11.2013 11:33, Richard Eckart de Castilho wrote:
>
>> On 02.11.2013, at 11:17, Thilo Goetz <tw...@gmx.de> wrote:
>>
>> On 01.11.2013 22:13, Marshall Schor wrote:
>>>
>>>>
>>>>
>> <snip>
>>
>> I don't know of any cases where the same FS was *intentionally* added to
>>>> the
>>>> indexes multiple times; so I'm hoping (!) that changing this behavior
>>>> won't
>>>> break existing things.
>>>>
>>>
>>> The why go to all this trouble to fix a non-existent issue?
>>>
>>
>> The current behavior is inconsistent and apparently undesired. We could
>> nail
>> the behavior down to a desired state before somebody starts relying on
>> it,
>> and runs into problems, e.g. when mixing remote and local operations, or
>> when
>> moving from local to remote. I'd consider being forced to maintain
>> inconsistencies
>> as another maintenance nightmare.
>>
>> -- Richard
>>
>>
> The current behavior of the local case is consistent, documented and
> works as designed. I have still not heard an argument that would
> convince me that adding the overhead Marshall is proposing to the
> local implementation is in any way more desirable or easier than
> to make the remote implementation consistent with the local one.
>
> --Thilo
>
>
Re: [jira] [Created] (UIMA-3399) More consistent handling of multiple
add-to-index behavior for same Feature Structure
Posted by Thilo Goetz <tw...@gmx.de>.
On 02.11.2013 11:33, Richard Eckart de Castilho wrote:
> On 02.11.2013, at 11:17, Thilo Goetz <tw...@gmx.de> wrote:
>
>> On 01.11.2013 22:13, Marshall Schor wrote:
>>>
>
> <snip>
>
>>> I don't know of any cases where the same FS was *intentionally* added to the
>>> indexes multiple times; so I'm hoping (!) that changing this behavior won't
>>> break existing things.
>>
>> The why go to all this trouble to fix a non-existent issue?
>
> The current behavior is inconsistent and apparently undesired. We could nail
> the behavior down to a desired state before somebody starts relying on it,
> and runs into problems, e.g. when mixing remote and local operations, or when
> moving from local to remote. I'd consider being forced to maintain inconsistencies
> as another maintenance nightmare.
>
> -- Richard
>
The current behavior of the local case is consistent, documented and
works as designed. I have still not heard an argument that would
convince me that adding the overhead Marshall is proposing to the
local implementation is in any way more desirable or easier than
to make the remote implementation consistent with the local one.
--Thilo
Re: [jira] [Created] (UIMA-3399) More consistent handling of multiple add-to-index behavior for same Feature Structure
Posted by Richard Eckart de Castilho <re...@apache.org>.
On 02.11.2013, at 11:17, Thilo Goetz <tw...@gmx.de> wrote:
> On 01.11.2013 22:13, Marshall Schor wrote:
>>
<snip>
>> I don't know of any cases where the same FS was *intentionally* added to the
>> indexes multiple times; so I'm hoping (!) that changing this behavior won't
>> break existing things.
>
> The why go to all this trouble to fix a non-existent issue?
The current behavior is inconsistent and apparently undesired. We could nail
the behavior down to a desired state before somebody starts relying on it,
and runs into problems, e.g. when mixing remote and local operations, or when
moving from local to remote. I'd consider being forced to maintain inconsistencies
as another maintenance nightmare.
-- Richard
Re: [jira] [Created] (UIMA-3399) More consistent handling of multiple
add-to-index behavior for same Feature Structure
Posted by Thilo Goetz <tw...@gmx.de>.
On 01.11.2013 22:13, Marshall Schor wrote:
>
> On 11/1/2013 11:59 AM, Thilo Goetz wrote:
>> On 01.11.2013 15:09, Marshall Schor (JIRA) wrote:
>>> Marshall Schor created UIMA-3399:
>>> ------------------------------------
>>>
>>> Summary: More consistent handling of multiple add-to-index
>>> behavior for same Feature Structure
>>> Key: UIMA-3399
>>> URL: https://issues.apache.org/jira/browse/UIMA-3399
>>> Project: UIMA
>>> Issue Type: Brainstorming
>>> Affects Versions: 2.4.2SDK
>>> Reporter: Marshall Schor
>>> Assignee: Marshall Schor
>>> Priority: Minor
>>>
>>>
>>> UIMA has a somewhat unusual indexing architecture. You can define indexes
>>> (sorted, bag, set), and then add / remove a feature structure (FS) to all of
>>> the defined indexes.
>>>
>>> The design intention (I think) was to support the concept of a FS being
>>> indexed, or not. However, the current design allows some anomalies that
>>> behave inconsistently between code being run "locally", versus as remote
>>> services (due to how serialization handles this). Serialization encodes only
>>> the concept of a FS being either in an index or not.
>>>
>>> The problem arises in the edge case where the same FS is added to the indexes
>>> multiple times. For local (non-remote) cases, for bag and sorted indexes,
>>> the same exact FS would be added multiple times. This would have the
>>> consequences:
>>>
>>> - Iterating would return multiple == FSs.
>>> - Remove from indexes of a multiply-added FS would reduce the number by 1;
>>> the FS would still be in the index.
>>>
>>> For the same code, running remotely, serialization would have "collapsed" the
>>> multiple additions into one, so would behave differently.
>>>
>>> A proposed improvement: Change the behavior of "add-to-index" so that
>>> subsequent add-to-indexes of a same FS would be either a no-op, or a delete /
>>> re-add (to cover the case where some feature values of the FS might have
>>> changed, and therefore leading to the need to re-index the FS). To cover
>>> users who might be exploiting the old behavior, we could have a framework
>>> context flag to re-instate the older behavior.
>>
>> The addition particularly of the bag index was an optimization. It is not an
>> index in the usual sense of the word. The advantage of putting things in a
>> bag index is that the cost is O(1). If you introduce a check for duplicates,
>> that removes that advantage completely.
> Thanks for commenting. I am hoping, though, keep this advantage :-).
>
> I presume your imagining that the way to check if a FS is indexed would be to go
> through one of the indicies for its type, element by element, element by
> element, and seeing if it is there.
>
> There could be other approaches. For example, we could imagine that there was
> a flag, one per FS and per indexRepository, which indicated if this FS had been
> "added-to-the-indexes". That approach might be able to trade off some space for
> keeping the order(1) performance.
>
>> It is the responsibility of the bag index user to make sure FSs are added only
>> as many times as necessary. There is a lot of old code that relies not
>> necessarily on the behavior with respect to duplicates, but that inserts
>> happen very fast.
>>
>> The only difference between a sorted and a set index is the fact that the
>> sorted index can contain the same element multiple times.
> There is a confusion, here, I think. The idea of set / sorted things is not
> based on the == identity of a FeatureStructure instance, but rather on the
> comparison of the defined keys. So I think the major use case for sorted
> indexes vs set indexes is not so much to have just one instance of an identical
> FS, but rather to have the equivalent set of "equal" FS, which are not identity
> equal, be considered as one unit.
>> So you are effectively proposing to eliminate the sorted indexes (and the bag
>> index, since it needs to be sorted to be efficient then).
>
> I'm not proposing to eliminate sorted indexes; they have the use case of
> allowing ordered iteration.
>
> I'm not proposing to eliminate set indexes; they have the use case of having
> keys-defined equivalency (sorry for the poor English...)
>
> And, I'm not proposing to eliminate the bag index, since I'm hoping we can find
> a space-efficient way to in order(1) time determine if a FS is in the state:
> added-to-indexes or not. A first design (which can probably be improved on)
> might do this as a Java BitSet, which would add 1 bit per 32-bit cell in the
> main heap, or about 3%, per "view". This might be able to be reduced further...
>
>>
>> I'm not necessarily against this change, but it seems odd to me that you want
>> to make the local case, which defined this behavior, adapt to the remote case,
>> which apparently didn't implement it correctly. I agree that it would
>> probably be good if there wasn't this inconsistency. OTOH, how many actual
>> indexes have you seen that contain duplicate FSs?
>
> I don't know of any cases where the same FS was *intentionally* added to the
> indexes multiple times; so I'm hoping (!) that changing this behavior won't
> break existing things.
The why go to all this trouble to fix a non-existent issue?
>
> -Marshall
>
>>
>> Like Richard, I'm -1 to a backwards compatibility flag. That's just a
>> maintenance nightmare, and it might change the behavior of annotators in
>> unforseen ways.
>>
>> Overall I'm -0 to this change. If there is strong support for it, that's fine
>> with me.
>>
>> --Thilo
>>
>>>
>>> This would better align how code running locally or remotely works.
>>>
>>> What do people think about this idea?
>>>
>>>
>>>
>>> --
>>> This message was sent by Atlassian JIRA
>>> (v6.1#6144)
>>>
>>
>>
>
Re: [jira] [Created] (UIMA-3399) More consistent handling of multiple
add-to-index behavior for same Feature Structure
Posted by Marshall Schor <ms...@schor.com>.
On 11/1/2013 11:59 AM, Thilo Goetz wrote:
> On 01.11.2013 15:09, Marshall Schor (JIRA) wrote:
>> Marshall Schor created UIMA-3399:
>> ------------------------------------
>>
>> Summary: More consistent handling of multiple add-to-index
>> behavior for same Feature Structure
>> Key: UIMA-3399
>> URL: https://issues.apache.org/jira/browse/UIMA-3399
>> Project: UIMA
>> Issue Type: Brainstorming
>> Affects Versions: 2.4.2SDK
>> Reporter: Marshall Schor
>> Assignee: Marshall Schor
>> Priority: Minor
>>
>>
>> UIMA has a somewhat unusual indexing architecture. You can define indexes
>> (sorted, bag, set), and then add / remove a feature structure (FS) to all of
>> the defined indexes.
>>
>> The design intention (I think) was to support the concept of a FS being
>> indexed, or not. However, the current design allows some anomalies that
>> behave inconsistently between code being run "locally", versus as remote
>> services (due to how serialization handles this). Serialization encodes only
>> the concept of a FS being either in an index or not.
>>
>> The problem arises in the edge case where the same FS is added to the indexes
>> multiple times. For local (non-remote) cases, for bag and sorted indexes,
>> the same exact FS would be added multiple times. This would have the
>> consequences:
>>
>> - Iterating would return multiple == FSs.
>> - Remove from indexes of a multiply-added FS would reduce the number by 1;
>> the FS would still be in the index.
>>
>> For the same code, running remotely, serialization would have "collapsed" the
>> multiple additions into one, so would behave differently.
>>
>> A proposed improvement: Change the behavior of "add-to-index" so that
>> subsequent add-to-indexes of a same FS would be either a no-op, or a delete /
>> re-add (to cover the case where some feature values of the FS might have
>> changed, and therefore leading to the need to re-index the FS). To cover
>> users who might be exploiting the old behavior, we could have a framework
>> context flag to re-instate the older behavior.
>
> The addition particularly of the bag index was an optimization. It is not an
> index in the usual sense of the word. The advantage of putting things in a
> bag index is that the cost is O(1). If you introduce a check for duplicates,
> that removes that advantage completely.
Thanks for commenting. I am hoping, though, keep this advantage :-).
I presume your imagining that the way to check if a FS is indexed would be to go
through one of the indicies for its type, element by element, element by
element, and seeing if it is there.
There could be other approaches. For example, we could imagine that there was
a flag, one per FS and per indexRepository, which indicated if this FS had been
"added-to-the-indexes". That approach might be able to trade off some space for
keeping the order(1) performance.
> It is the responsibility of the bag index user to make sure FSs are added only
> as many times as necessary. There is a lot of old code that relies not
> necessarily on the behavior with respect to duplicates, but that inserts
> happen very fast.
>
> The only difference between a sorted and a set index is the fact that the
> sorted index can contain the same element multiple times.
There is a confusion, here, I think. The idea of set / sorted things is not
based on the == identity of a FeatureStructure instance, but rather on the
comparison of the defined keys. So I think the major use case for sorted
indexes vs set indexes is not so much to have just one instance of an identical
FS, but rather to have the equivalent set of "equal" FS, which are not identity
equal, be considered as one unit.
> So you are effectively proposing to eliminate the sorted indexes (and the bag
> index, since it needs to be sorted to be efficient then).
I'm not proposing to eliminate sorted indexes; they have the use case of
allowing ordered iteration.
I'm not proposing to eliminate set indexes; they have the use case of having
keys-defined equivalency (sorry for the poor English...)
And, I'm not proposing to eliminate the bag index, since I'm hoping we can find
a space-efficient way to in order(1) time determine if a FS is in the state:
added-to-indexes or not. A first design (which can probably be improved on)
might do this as a Java BitSet, which would add 1 bit per 32-bit cell in the
main heap, or about 3%, per "view". This might be able to be reduced further...
>
> I'm not necessarily against this change, but it seems odd to me that you want
> to make the local case, which defined this behavior, adapt to the remote case,
> which apparently didn't implement it correctly. I agree that it would
> probably be good if there wasn't this inconsistency. OTOH, how many actual
> indexes have you seen that contain duplicate FSs?
I don't know of any cases where the same FS was *intentionally* added to the
indexes multiple times; so I'm hoping (!) that changing this behavior won't
break existing things.
-Marshall
>
> Like Richard, I'm -1 to a backwards compatibility flag. That's just a
> maintenance nightmare, and it might change the behavior of annotators in
> unforseen ways.
>
> Overall I'm -0 to this change. If there is strong support for it, that's fine
> with me.
>
> --Thilo
>
>>
>> This would better align how code running locally or remotely works.
>>
>> What do people think about this idea?
>>
>>
>>
>> --
>> This message was sent by Atlassian JIRA
>> (v6.1#6144)
>>
>
>
Re: [jira] [Created] (UIMA-3399) More consistent handling of multiple
add-to-index behavior for same Feature Structure
Posted by Thilo Goetz <tw...@gmx.de>.
On 01.11.2013 15:09, Marshall Schor (JIRA) wrote:
> Marshall Schor created UIMA-3399:
> ------------------------------------
>
> Summary: More consistent handling of multiple add-to-index behavior for same Feature Structure
> Key: UIMA-3399
> URL: https://issues.apache.org/jira/browse/UIMA-3399
> Project: UIMA
> Issue Type: Brainstorming
> Affects Versions: 2.4.2SDK
> Reporter: Marshall Schor
> Assignee: Marshall Schor
> Priority: Minor
>
>
> UIMA has a somewhat unusual indexing architecture. You can define indexes (sorted, bag, set), and then add / remove a feature structure (FS) to all of the defined indexes.
>
> The design intention (I think) was to support the concept of a FS being indexed, or not. However, the current design allows some anomalies that behave inconsistently between code being run "locally", versus as remote services (due to how serialization handles this). Serialization encodes only the concept of a FS being either in an index or not.
>
> The problem arises in the edge case where the same FS is added to the indexes multiple times. For local (non-remote) cases, for bag and sorted indexes, the same exact FS would be added multiple times. This would have the consequences:
>
> - Iterating would return multiple == FSs.
> - Remove from indexes of a multiply-added FS would reduce the number by 1; the FS would still be in the index.
>
> For the same code, running remotely, serialization would have "collapsed" the multiple additions into one, so would behave differently.
>
> A proposed improvement: Change the behavior of "add-to-index" so that subsequent add-to-indexes of a same FS would be either a no-op, or a delete / re-add (to cover the case where some feature values of the FS might have changed, and therefore leading to the need to re-index the FS). To cover users who might be exploiting the old behavior, we could have a framework context flag to re-instate the older behavior.
The addition particularly of the bag index was an optimization. It is
not an index in the usual sense of the word. The advantage of putting
things in a bag index is that the cost is O(1). If you introduce a
check for duplicates, that removes that advantage completely. It is the
responsibility of the bag index user to make sure FSs are added only as
many times as necessary. There is a lot of old code that relies not
necessarily on the behavior with respect to duplicates, but that inserts
happen very fast.
The only difference between a sorted and a set index is the fact that
the sorted index can contain the same element multiple times. So you
are effectively proposing to eliminate the sorted indexes (and the bag
index, since it needs to be sorted to be efficient then).
I'm not necessarily against this change, but it seems odd to me that you
want to make the local case, which defined this behavior, adapt to the
remote case, which apparently didn't implement it correctly. I agree
that it would probably be good if there wasn't this inconsistency.
OTOH, how many actual indexes have you seen that contain duplicate FSs?
Like Richard, I'm -1 to a backwards compatibility flag. That's just a
maintenance nightmare, and it might change the behavior of annotators in
unforseen ways.
Overall I'm -0 to this change. If there is strong support for it,
that's fine with me.
--Thilo
>
> This would better align how code running locally or remotely works.
>
> What do people think about this idea?
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.1#6144)
>