On 5/11/07, Marshall Schor <[EMAIL PROTECTED]> wrote:
Adam wrote:
> Next thought... what if instead of the separate _Type objects, you
> maintained in the JCasImpl a map from JCas object to "home view". As
> above you only need to do this for non-annotation objects that have
> indexes defined for them (AND if the home view is not the initial
> view, since that could be the default).
>
> That has different performance characteristics which may or may not
> necessarily be better (it depends on how many instances get created I
> think), but maybe it is a cleaner way to stay compatible.
Not sure I follow this... Let's see - you would have one generator set,
which iterators would use to generate a cover instance, for all the
different views, . If a cover instance already existed, you would need
to examine this map-to-home-view, and see if the home view was the right
one. If not, you would generate an additional cover instance. The
cache from key=CAS addr to value=cover-JCas-instance would need to map
to a collection of cover-JCas-instances, possibly one per view in which
it was indexed. Is this what you were thinking?
Not quite. I was imagining only one cover-JCas-instance per FS. The
idea was to move the information that associates a cover-JCas-instance
with a view out, taking it out of the instance and moving it into a
map that's stored in the JCas. The JCAS would store a map from the
cover-JCAS-instance to whichever view that instance was originally
created against, and addToIndexes() would always use that.
On further thought I don't think I like the performance implications
of that, though, since if someone creates many instances of the same
non-annotation type we'd have an entry in the map for all of them. So
maybe forget that idea.
-Adam
