You are here: Home V2 Software Software More ... Developer Notes Legacy Notes Backwards Compatibility for Python/XML v1.0-v1.1

Backwards Compatibility for Python/XML v1.0-v1.1

Implementation of backwards compatibility. General ideas and Python/XML I/O version.

Plan:


Compatibility I/O map to be based on target. Remaming and skipping relative to
source added automatically. Attributes and links of conserved objects present
only in old version are marked as 'delay' always. Attributes with incompatible
type changes (e.g. flost->int) have the type of the attribute changed in the map
and are set as 'delay'

In the simple case the new I/O map combined with handcode to interpret 'delayed'
and create missing bits will be enough. This can be done on XML reading or
(with some messy  preparation) API-to-API. 'Delayed' attributes are handled in
handcode after link dereferencing but before child connection. Forwards and
backwards compatibility would require parallel directories with compatibility
info.

For information we need:
- A file with general-use functions (e.g. restrictToPositive or toWord)
- A file with specific functions, accumulated over versions. 
Functions to be of the form  func(obj, compDict, topObjByGuid)
- For each old version two files: one with the model comparison (skip, delay,
rename, as well as other information for info only). Another with a dictionary
of class.guid:list-of-functions to apply on delayed data. Priority system to be
ignored for the time being. Each file could import from other files in the list.

A file structure like this would do:
compatibility/
definedVersion/
generalFunctions.py
upgrade/
specificFunctions.py
olderVersion1/
IOMapInfo.py
functionSelection.py
olderVersion2/
...
downgrade/
specificFunctions.py
olderVersion1/
IOMapInfo.py
functionSelection.py
olderVersion2/
...




For cases where parent graph or fullkeys change, classes split, or information
must move from skipped objects, we use API-to-API conversion (forwards or
backwards).

Procedure is:
- Load all data you wish to convert (in old API).
- Change to new API Python path
- Generate compatibility I/O map fronm file as above (Auto).
- Make new Implementation package and establish object-to-object mapping.
Auto on standard procedure (below) in most cases
- Load new reference data and establish object-to-object mapping to old data.
Auto on identical keys in most cases. Handcode may be needed.
- Modify old object network in place so that it maps to new parent-child graph
(remove  add, split objects, using dummy classes as required). Handcode. 
- Loop over old object network, using I/O mappings to create new objects
and populate Attributes (Auto)
- Loop over old object network dereferencing links using object-to-object map
(Auto)
- Fix 'delay' objects and run handcode as for simple case. Use newObj,
oldObj.__dict__ as input.At this point everything should be corrected.
- Connnect parent-child links.
- Handcode should be func(oldMemopsRoot, newMemopsRoot, objMapDict)

Information to handle by hand in 1.0->1.1 transition:

- ccpCode translation (Except in reference data files)?
- Annotation.url (link -> CDType)
- Make BlockedBinaryMatrix from Nmr.DataSource and Nmr.AbstractDataDim
- ccp.nmr.Nmr.DataSource.noiseLevel to NonNegative
- ccp.nmr.Nmr.FidDataDim.numPointsValid to NonNegative
- ccp.nmr.Nmr.AbstractDataDim.numPoints to NonNegative
- ccp.molecule.MolStructure.MolStructure and relevant links
- ccp.molecule.Molecule.MolResidue.chemComp

- Fix isSplitting=true in NmrExpPrototype. (ONLY HNCACO) by hand
- NBNB Analysis.StoredContour.url

Classes to make:
CDType Url
DataLocation: DataUrl, RelativePath, BlockedBinaryMatrix