SIRA_PRISE Upgrading from previous versions

Upgrading from 1.4 to 1.5

Upgrading existing 1.4 installations to 1.5 is somewhat more laborious than previous upgrades. The process breaks down in the following major pieces :

  1. Install 1.5 alongside your current installation, leaving the latter fully operational.
  2. Migrate your database definitions. This includes all the types & operators, all the logical design definitions and all the physical design definitions.
  3. Unload your data from the existing installation and upload it to your new 1.5 installation.

Migrating database definitions

Just like the actual data, your database definitions will have to be unloaded from the catalog of your existing installation, and uploaded into your 1.5 installation. This section is intended to discuss and provide helpful material for accomplishing that task.

  1. Migrating your Types & Operator definitions

    If you have defined any additional types and/or operators, they must be uploaded to the 1.5 installation. Any operators you've implemented must be explicitly registered in the 1.5 installation. Types can be registered in the 1.5 installation by executing the same catalog updates you used to register them in the 1.4 installation, or by copying the current value of the involved catalog relvars over to your 1.5 installation, e.g. using the following queries :

    Helpful queries for migrating type definitions
    Catalog relvar to migrate 1.4 catalog query
    JAVABACKEDTYPE SEMIMINUS( JAVABACKEDTYPE , SYSTEMDEFINEDTYPE)
    CONSTRAINEDTYPE, USERDEFINEDTYPE, UDTORDERINGOPERATOR, UDTPOSSREP, UDTPOSSREPCOMPONENT, UDTHYSICALPOSSREPCOMPONENT, UDTPPCVALUESELECTOR These relvars have remained unchanged. Just copy their contents over to 1.5.

  2. Migrating your Attributes definitions

    Your applications' business model attributes must be entered into the 1.5 installation. The following observations apply :

    Helpful queries for migrating attribute definitions
    Catalog relvar to migrate 1.4 catalog query
    ATTRIBUTE The relvar has remained unchanged, but there is no straightforward way to distinguish between the user attributes and the catalog attributes. The following query achieves that :SEMIMINUS(ATTRIBUTE,PROJECT(JOIN(RELVARATTRIBUTE,SYSTEMDEFINEDRELVAR),(ATTRIBUTENAME)))
    ATTRIBUTELOGICALLENGTH This relvar has been dropped from the catalog, and replaced with ATTRIBUTELENGTHCONSTRAINT. The following query retrieves an appropriate value for the ATTRIBUTELENGTHCONSTRAINT relvar from ATTRIBUTELOGICALLENGTH : SEMIMINUS(TRANSFORM(ATTRIBUTELOGICALLENGTH,(MAXIMUMLENGTH(LOGICALLENGTH))),PROJECT(JOIN(RELVARATTRIBUTE,SYSTEMDEFINEDRELVAR),(ATTRIBUTENAME)))

  3. Migrating your logical designs

    Your applications' business model logical designs must be entered into the 1.5 installation. The following observations apply :

    Helpful queries for migrating logical designs
    Catalog relvar to migrate 1.4 catalog query
    RELVAR, KEY, RELVARATTRIBUTE, VIRTUALRELVAR These relvars have remained unchanged. Copy them over using e.g. the following queries :SEMIMINUS( relvar ,SYSTEMDEFINEDRELVAR)
    KEYATTRIBUTE, TUPLECONSTRAINT, DATABASECONSTRAINT, ASSIGNMENTCONSTRAINT, CONSTRAINTMESSAGETEXT These relvars have remained unchanged. Copy them over using e.g. the following queries :SEMIMINUS( relvar ,SYSTEMDEFINEDCONSTRAINT)

  4. Migrating your files & storagespace definitions.

    The physical data recording facilities have been drastically changed (and drastically simplified). The following observations apply :

    Helpful queries for migrating physical design resources
    Catalog relvar to migrate 1.4 catalog query
    DBMSFILE Relvars has remained unchanged. Copy them over using e.g. the following queries :SEMIMINUS(DBMSFILE,SYSTEMDEFINEDDBMSFILE). Note that excluding the SYSTEMDEFINEDDBMSFILE applies to all the following entries as well, and will not be repeated each time again.
    STORAGESPACE, STORAGESPACEEXTENT These relvars have been combined into one. The following query gets an appropriate value for uploading into the 1.5 installation :LEFTJOIN(STORAGESPACE,STORAGESPACEEXTENT,EXTENTSCOUNT(INT(0)))
    DATASPACE, MULTIHASHINGINDEXSPACE Each DATASPACE and each MULTIHASHINGINDEXSPACE must be converted into a HASHEDRECORDSPACE. The current value of both relvars is appropriate for achieving this (i.e. an appropriate query is simply DATASPACE)
    HASHINGINDEXSPACE Each HASHINGINDEXSPACE must be converted into a HASHEDRECORDSPACE. A MAXIMUMGAPCOUNT and GAPCOMPRESSIONTHRESHOLD must be chosen to achieve this : EXTEND(HASHINGINDEXSPACE,(MAXIMUMGAPCOUNT(9)GAPCOMPRESSIONTHRESHOLD(5)))
    HASHINGINDEXSPACES must not necessarily be migrated if there is currently no index stored in them : EXTEND(SEMIJOIN(HASHINGINDEXSPACE,INDEX),(MAXIMUMGAPCOUNT(9)GAPCOMPRESSIONTHRESHOLD(5))), but in this case observe that you must also exclude the concerned tuples from the STORAGESPACE relvar ...
    TREEINDEXSPACE Each TREEINDEXSPACE must be converted into a CLUSTEREDRECORDSPACE. The current value of the relvar is appropriate for achieving this (i.e. an appropriate query is simply TREEINDEXSPACE)
    new CLUSTEREDRECORDSPACELOCATTRS Each CLUSTEREDRECORDSPACE must be assigned a specification of the attributes constituting its indexing key. This is the current set of attributes that constitute the indexing key for any INDEX stored in a TREEINDEXSPACE : PROJECT(JOIN(INDEXATTRIBUTE,INDEXCOMPONENT,INDEX,TREEINDEXSPACE),(FILENAME,STORAGESPACEID,ORDINAL,ATTRIBUTENAME)))

  5. Migrating your recorddtype & index definitions.

    Recordtypes & indexes as distinct concepts, have been mergered into the single concept of "recordtype". The following observations apply :

    Helpful queries for migrating physical designs
    Catalog relvar to migrate 1.4 catalog query
    RECORDTYPE There is no longer a need to associate a "locating index" with any record type. For supporting the new encoding scheme, an additional attribute "MAXIMUMLENGTH" must be chosen, which can be copied over from the RECORDTYPEID relvar :SEMIMINUS( TRANSFORM(JOIN(RECORDTYPE,RECORDTYPEID),(RELVARNAME,RECORDTYPENAME,FILENAME,STORAGESPACEID,MAXIMUMLENGTH(PHYSICALLENGTH))) ,SYSTEMDEFINEDRELVAR). Note that excluding the SYSTEMDEFINEDRELVARs applies to all the following entries as well, and will not be repeated each time again.
    RECORDATTRIBUTE Record attributes can be copied over from the current situation :RECORDATTRIBUTE
    INDEX Each INDEX must also be converted into a RECORDTYPE, except if it is the current locator index for the record type. A new unique RECORDTYPENAME must be assigned, and a MAXIMUMLENGTH, which can once again be copied over from the current RECORDTYPEID relvar : RENAME(TRANSFORM(JOIN(SEMIMINUS(INDEX,PROJECT(RECORDTYPE,(INDEXNAME))),RECORDTYPEID),(RELVARNAME, NEWRECORDTYPENAME(NAME(CONCAT(THE_STRING(INDEXNAME),THE_STRING(RECORDTYPENAME)))), FILENAME, STORAGESPACEID, MAXIMUMLENGTH(PHYSICALLENGTH))) , (NEWRECORDTYPENAME,RECORDTYPENAME)))

Migrating your data

This will involve retrieving the current value of each of your relvars from your current database, and inserting that value into the same relvar in the new installation. If you have complex constraints governing your data, it might be useful to consider migrating the data BEFORE migrating the constraints.