[
https://issues.apache.org/jira/browse/UIMA-5106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15605216#comment-15605216
]
Richard Eckart de Castilho commented on UIMA-5106:
--------------------------------------------------
Being used to UIMA managing IDs, I would prefer that UIMA continues to manage
the IDs and that is automatically and always assigns them - just like a
database auto-increment primary key. I would also prefer if they continue to be
kept separate from the features space.
IMHO using an int ID should be sufficient. Int worked so far... long would be
nice... but not really important.
IMHO all feature structures should have the ID, even the FSArray.
> uv3 constant "id" for FSs (Proposed new Feature for uv3)
> --------------------------------------------------------
>
> Key: UIMA-5106
> URL: https://issues.apache.org/jira/browse/UIMA-5106
> Project: UIMA
> Issue Type: New Feature
> Components: Core Java Framework
> Reporter: Marshall Schor
> Priority: Minor
> Fix For: 3.0.0SDKexp
>
>
> Add constant ID for FSs. This would be an incrementing, long value. It would
> be constant through serialization/ deserialization cycles. There would be a
> lazily created map from longs to FSs (via weak links) to allow direct access
> from the ID to the FS. Lazy intent is to not have a cost for this
> (space/time) other than the cost for 1 long / FS, if it is not used.
> We could make this feature optional, as well, to avoid the 8 bytes per FS
> overhead, but in V3, I think that's not a good tradeoff (space savings vs
> complexity).
> Issues:
> * Current design allows parallelism of services, with returned results
> "stacked" into receiving CAS; would need to change (some of) the IDs coming
> back.
> CAS would need to have the high-water-mark value as part of serializations.
> Backwards compatibility:
> * loading V2 CASs: generate new IDs upon loading.
> * serializing to V2: (for connecting to V2 services): drop the IDs.
> This is a proposed new V3 feature; comments appreciated.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
