[ https://issues.apache.org/jira/browse/UIMA-5106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15605577#comment-15605577 ]
Richard Eckart de Castilho commented on UIMA-5106: -------------------------------------------------- Hm, ok. So then I am not sure if this feature here is needed. If users want to assign own stable IDs, then they can create a feature for that and are good. But users cannot create new features on high-level types (e.g. on TOP or Annotation) - is it that you wanted to introduce a "blessed" external ID feature that all FSes would inherit? > 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)