One other slight edge case - In the case below (1) where the source and destination CASs are the same, I think it would be best to throw an error if the source view == the destination view, because I can't think of a valid use case for this, and it seems much more likely to be a mistake.
-Marshall On 6/18/2013 10:09 AM, Marshall Schor wrote: > In the following use case, what should be the result: > > 1) Source and target CASs have the same base CAS (that is, they might be 2 > different views). Currently - there's no check for this, and what happens is > that the existing reachable feature structures are copied (making duplicates) > and those are indexed in the new view, and the sofa data is optionally > copied. > Because the new view has its own Sofa, any annotation (which has a reference > to > the Sofa) would not be == (it would have a reference to the copied sofa). So, > the copying is probably required (at least for subtypes of AnnotationBaseFS). > > I plan to keep this behavior. > > 2) Target CAS has some Feature Structure Instances that are the "same" as > the > Source CAS. My suggestion - ignore this, and just add (another) instance. > (Currently, this is what happens). "Same-ness" is hard to define, especially > if > "lenient" is in effect. > > ----- > Another little change: > > If a Sofa reference isn't set, the current code (for AnnotationFS and > subtypes) > sets this to the Sofa. This is so that adding this FS to the indexes doesn't > fail when it is attempted to be added to the built-in Annotation Index. It > seems to me this should be extended to general annotations (AnnotationBaseFS > and > subtypes), to cover non-text style annotations. > > ----- > The APIs: > > Currently the API is a 2-level one, plus some Static methods to hide this. > The > 2-level one: > a) make an instance of the CAS Copier, passing in both CASes. Also set a > lenient flag. > b) A copyView method: arguments are some representation of the View, and a > flag which says whether or not to copy the Sofa. > > There are 2 common ways to specify a view: > a) by view name - a string > b) by an instance of the the CAS which is that particular view > > I plan to uniformly allow both styles. So there will be: > > copyCasView(CAS aSrcCasView, boolean > aCopySofa) <<< currently exists > copyCasView(String aSrcCasViewName, boolean > aCopySofa) > > copyCasView(CAS aSrcCasView, CAS aTgtCasView, boolean > aCopySofa) > copyCasView(String aSrcCasViewName, String aTgtCasViewName, boolean > aCopySofa) > > copyCasView(CAS aSrcCasView, String aTgtCasViewName, boolean > aCopySofa) > copyCasView(String aSrcCasViewName, CAS aTgtView, boolean > aCopySofa) > > Let me know if there are other opinions here... > > -Marshall > > > > > On 6/17/2013 2:09 PM, Joern Kottmann (JIRA) wrote: >> [ >> https://issues.apache.org/jira/browse/UIMA-2409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13685786#comment-13685786 >> ] >> >> Joern Kottmann commented on UIMA-2409: >> -------------------------------------- >> >> Yes, the patch should be reviewed before it is applied. I was not confident >> that it works for all the edge cases. Can you have a look Marshall? >> >>> CasCopier.copyCasView should be able to copy into a view with a different >>> name >>> ------------------------------------------------------------------------------ >>> >>> Key: UIMA-2409 >>> URL: https://issues.apache.org/jira/browse/UIMA-2409 >>> Project: UIMA >>> Issue Type: Improvement >>> Components: Core Java Framework >>> Reporter: Joern Kottmann >>> Priority: Trivial >>> Fix For: 2.4.1SDK >>> >>> Attachments: UIMA-2409.patch >>> >>> >>> The CasCopier should be able to copy a CAS view into a new CAS and giving >>> this new CAS view a different name. >>> A common use case is to copy a view of multi view CAS into a new single >>> view CAS. >> -- >> This message is automatically generated by JIRA. >> If you think it was sent incorrectly, please contact your JIRA administrators >> For more information on JIRA, see: http://www.atlassian.com/software/jira >> >
