The CasIOUtils API uses an enum CasLoadMode, currently having 3 values: DEFAULT, LENIENT, and REINIT
Propose adding the local config for this by adding 3 new enums: DEFAULT_PRESERVE_V2_IDS, LENIENT_PRESERVE_V2_IDS and REINIT_PRESERVE_V2_IDS The existing APIs already are designed to take one instance of the CasLoadMode, so these have to be multiplied out, it seems. -Marshall On 12/4/2017 9:36 AM, Marshall Schor wrote: > I've thought a bit about generalizing this. Since V3 supports arbitrary Java > objects in the CAS, users could construct their own custom mapping between ids > (ints or strings or ...) and FSs and carry these around in the CAS, with weak > or > strong references, using plain or linked hashmaps (if iteration order was > important), etc. > > Using something like that would still require some kind of bridge or migration > code, so the deserializers which use the V2 addresses (for backwards > compatibility) could "dump" these into whatever kind of map users wanted. > > ----------------- > > There is a backwards compatibility concern, though, where it would be nice to > run applications which depended on this in V3. An implementation "mode" could > do this as follows: > > Use the mode to modify some operations: > > 1) modify deserialization operations (for those deserializers where they are > maintaining a v2 id mapping to FSs): at the end, dump the v2 id map to fss > into > either: > a linked hash map with weak references > and special code to remove entries > when the weak reference is gc'd, or > just the currently existing map used for low-level cas fs-creation > which does not use weak refs (required) > > 2) a way to access this new map: either overload the current low level > accessors > (if alternative 1) based on the "mode" to use this new map, or provide a > different API (would imply less backwards compatibility). > > 3) new serialization to have the serialized id's match the saved ones. This > could be implemented by having the deserialization install the v2 id's as the > v3 > ids, and then set the internals so new id's would be created after the highest > deserialized id. This approach would facilitate reusing the existing low > level > APIs for this. > > The mode could be set programmatically (which would require modifying the > application of course) or via a -Duima.xxxx style of start-up configuration > option (-Duima.v2_deserialize_preserve_ids). > > ==================== > > I propose to implement this focusing more on making it backward-compatible, > reusing the existing low-level APIs and the internal maps they use (which are > not weak refs), and an external flag (which should permit running a V2 > application unmodified), plus some local config option whose default value is > set from the external flag. > > WDYT? > > -Marshall > > >
