Adam Lally wrote:
There's another issue with JCas we haven't considered yet - the
addToIndexes() method on JCasGen-erated classes. When this is called,
it needs to know what index repository (what view) to index them in.
Same for removeFromIndexes() of course :-)
Currently, this uses whichever view (meaning a JCas instance) was
passed to the constructor when the object was created. With this
refactoring, new objects would presumably be given a reference to the
one-and-only JCas, never a JCasView.
Single-sofa code could be made to work using the same "current view"
idea already discussed. But multi-sofa code will have a problem.
So I think we need to deprecate addToIndexes().
Not sure about this - because the "current view" mechanism would
seem to make this work, even for multi-sofa. We could even put in
code that checked if the item being indexed was a subtype of AnnotationBase,
and if so, indexed it in the proper view (if the current view had a Sofa
but it
was the "wrong" one).
To intentionally index a JCas cover object in another View, there is
always the
otherJCasView.addToIndexes(FS) method.
So I'm not sure about the value of deprecating this.
We can add a new
method addToIndexes(JCasView) in its place,
I like (prefer) this, but admit it seems redundant with the following
and/or require the use of
JCasView.addToIndexes(FS) instead.
-Marshall
