Thanks Richard, We never had problems migrating from one type system as long the types where either extended or something was deleted. The problem we had was when an attribute changed type, e.g. a change from a simple FSArray to a wrapper type with the custom java object and a FSArray. We tried something similar last year where a type A had an FSArray attribute with elements of another type B that previously inherited from Annotation, and we changed that to inherit from TOP instead, while all of the attributes of B, that we had declared, remained unchanged. Not surprisingly the deserialiser couldn’t load the old CAS leniently with this change, and we never figured out how to do a conversion, if that is at all possible, since A can only take one form, i.e. we haven’t figured out how to have two versions of A simultaneously in order to make a conversion. Maybe there are some lower level CAS possibilities that we are not aware of yet. The problem should be the same when changing the type of an attribute from FSArray to a wrapper type with custom java objects.
Cheers Mario > On 21 Oct 2020, at 09.15, Richard Eckart de Castilho <r...@apache.org> wrote: > > External email – Do not click links or open attachments unless you recognize > the sender and know that the content is safe. > > > Hi Mario, > >> On 18. Oct 2020, at 11:49, Mario Juric <mario.ju...@cactusglobal.com> wrote: >> >> I experimented with the CAS-transported custom Java objects feature, and I >> found that it’s indirectly possible to use them with JCasGen by following >> the guidelines to wrap each custom Java object in an UIMA type, which can be >> reused as an attribute or through inheritance in the type system. The custom >> type will have to be handcrafted though, but that is a small thing, and >> JCasGen can be used to generate the initial template, but this is all >> covered in the documentation. > > Good you found a workaround :) > > Personally, I think evolving the type system description / JCasGen a bit > would be a good idea. In particular, I would like to see the ability to > specify interfaces that a given generated type should implement. > >> There is a trade off in our case, it will break with the type system of a >> large number of existing binaries that we saved, since we already use >> FSArray where we currently wanna replace it with some custom Java object. I >> am not sure how big this issue is for others, but we have some large data >> sets that we prefer not to reprocess from scratch too often, although it >> will happen at some point. Nevertheless, this design trick brings us some of >> the way even though it’s not "the full monty” as I imagine. > > Well, this sounds like a format conversion. So in principle, you wouldn't > need to re-process all the data but rather to implement a pipeline which > reads the old format, transfers the information that changed into the new > CAS-transported objects, removes the old objects, and writes the result out > again. I would hope that the UIMA APIs ((J)Cas, pipeline concept) would > support that reasonably well. Of course, it means implementing some Java code > and not just to have some "simple" declarative language. But then again, in > the general case, such conversions can be arbitrarily complex and "simple" > transformation language tend to hit their limits soon or they are not > "simple" anymore... in which case a proper language like Java could have been > already used in the first place. > > Cheers, > > -- Richard ________________________________ Disclaimer: This email and any files transmitted with it are confidential and directed solely for the use of the intended addressee or addressees and may contain information that is legally privileged, confidential, and exempt from disclosure. If you have received this email in error, please notify the sender by telephone, fax, or return email and immediately delete this email and any files transmitted along with it. Unintended recipients are not authorized to disclose, disseminate, distribute, copy or take any action in reliance on information contained in this email and/or any files attached thereto, in any manner other than to notify the sender; any unauthorized use is subject to legal prosecution.
