Hmmm, I didn't see this in time... I would need to think through the implications. One thing to watch out for - the copyCasView is used as a subroutine for the full cas copy - which iterates over all views calling this. The full cas copy should be a faithful copy - so this would need thinking through.
I'm tempted though to move on, unless there's some issues that come up. (I look forward to others testing / wringing-out-the-bugs :-) ) -Marshall On 6/18/2013 2:18 PM, Richard Eckart de Castilho wrote: > 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 >> >
