[
https://issues.apache.org/jira/browse/UIMA-5662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16283724#comment-16283724
]
Richard Eckart de Castilho commented on UIMA-5662:
--------------------------------------------------
If I wanted to store the IDs explicitly, I'd add a corresponding feature to my
annotation types or I'd create this kind of FS that you are describing.
Personally, I appreciate having the ID directly built in to the system
*outside* the type system and to be relieved from ID management. In fact, for a
different use-case, some annotations in my type system already include an ID
field. But the scenarios in which I make use of the FS addresses and the ID
fields are entirely different.
I find the built-in low-level IDs in particular useful for the case where one
builds a visual editor to manipulate the CAS contents. And specifically in the
case where the editor does not keep the CAS in memory all the time (e.g.
because unlike the CAS editor, it is a web-based editor) the stable
serializable IDs come in very handy. I have already contemplated adding an
editor-specific "__id__" feature to all types in the type system but then I'd
have to generate that on import, filter it out on export, manage the IDs
myself... hmm... no, rather not.
> uv3 support CAS deserialization subsequent low level access
> -----------------------------------------------------------
>
> Key: UIMA-5662
> URL: https://issues.apache.org/jira/browse/UIMA-5662
> Project: UIMA
> Issue Type: Improvement
> Components: Core Java Framework
> Affects Versions: 3.0.0SDK-beta
> Reporter: Marshall Schor
> Assignee: Marshall Schor
> Priority: Minor
> Fix For: 3.0.0SDK
>
>
> Some users depend 1) constant v2-ids for FSs preserved in deserialization and
> serialization, and 2) low level cas API access to these.
> V3 normally doesn't maintain tables linking ids to FSs, as these (unless weak
> refs are used) prevent GC of unreachable FSs.
> Based on a mode, set by -Duima.deserialize_perserve_ids, and also
> controllable by new config option per deserialize call, alter the
> deserialization for those deserializers which know about v2 ids, to put these
> into the map used for low-level CAS access, using the actual v2 ids, and
> change the v3 next available id for future new FSs to be 1 beyond the end.
> The -Duima.deserialize-preserve_ids global setting is needed to handle the
> use case of some annotators using low-level APIs, when part of a pipeline is
> "remoted".
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
