I think a conservative approach may be wise. Just copy the source view to the target view and not create any cross-linked views. Either throw an error when data is cross-linked, or just leave the linking features empty (null).
I think feature for copying cross-lnks would be worth an additional feature request. If linked features be copied to the target CAS (we are no longer talking about view-to-view copying here), then it should be controllable. E.g. the user should be able to provide the CasCopier with a callback that can decide if a particular link (across a view boundary) should be followed or not. I believe the use-cases we have right now are: 1) copy view X from Base-CAS A to Base-CAS B 2) copy view X to view Y in same Base-CAS I'd suggest to not do more than exactly that. -- Richard Am 18.06.2013 um 19:26 schrieb Marshall Schor <[email protected]>: > An edge case involving cross-view references: > > Each AnnotationBaseFS (or subtype) holds a reference to the SofaFS it is an > annotation over. > > Although these annotations may only be indexed in the view having the sofa > they > are annotations over, it is possible that Instances of these may be referenced > in other views (cross-view linking). > > When just one "view" is copied, these references end up referring to SofaFS > representing other views. The current copier implementation is to get/create > these views in the target. The sofas, if created, have no Sofa Data. This > is > one thing that could be changed: we could honor the boolean flag, aCopySofa, > in > the API which controls whether or not the top level sofa for the view being > copied, has its data copied. > > When doing a view copy to another view with a different name, I think the > implementation needs to > - check if the view associated in the source is the view being copied, and > if so, > - it should use the new target view. > - if the view is not the same as the source being copied, then we could > either > throw an exception, or silent/under-the-covers, create this additional view > (with the same name as in the source) in the target. An ambiguity might occur > if the source's view name just happened to match the new target view name, I > suppose, but normally, this would result in additional views (other than the > one > specified) being created as a side effect of copyCasView. My suggestion is to > not throw an exception, but just to go ahead and create (or reuse) the > samed-named views in this case. My rational is that this is an unlikely case > in > the first place (it requires an advanced concept - cross-view linking), and so > accidental occurrences should be rare; it also has potentially some benefits - > allowing cas view copying in these cases, where it's probably unlikely the > user > would even be referencing these cross-view links. Also, for this case we > have > the same issue of not setting in the destination CAS the sofa data that might > be > present for these other views. > > I plan to follow the current impl in *not* copying the sofa data for any new > views we might create via cross linking. If a user wanted these, they can > always set the sofa data explicitly from the other CAS (a manual copy); but I > think it's unlikely they's be wanted. > > ----------- > A similar special case exists for the DocumentAnnotation - there can be 0 or 1 > of these per view in the CAS. But other FSs (perhaps in other views) can hold > references to this FS (cross linking). The same kind of view-switching (if > the > source view is the view being copied, use the target view name instead) would > be > used for this. > > WDYT? > > -Marshall >
