LSB Versions Support in the Database

From ISP_RAS
Jump to: navigation, search

Contents

Data Fields for LSB Versions Support

Specification database contains information about LSB version history. For every element, it is possible to know when it appeared in the standard, when it became deprecated and when it was withdrawn. Such information is stored in fields whose names end with appearedin, deprecatedsince and withdrawnin. Since most elements can have different LSB status on different architectures, 'appearedin' and 'withdrawnin' fields have been added to the tables that implement N-to-N relationship between the element's table and the Architecture table. Deprecation process affects all interfaces, so 'deprecatedsince' field is added directly to entities tables.

These fields have varchar type and simply contain LSB version number ('2.0','3.1', etc.). 'withdrawnin' field can be NULL (and it is NULL by default), 'appearedin' field cannot have NULL value and by default it is empty.

The following tables have 'deprecatedsince' field:

  • Interface
  • Command
  • Library

The following *Arch* tables have 'appearedin' and withdrawnin' fields:

  • ArchClass
  • ArchConst
  • ArchInt
  • ArchLib
  • ArchType
  • ArchDE
  • ArchES

Some kinds of elements are architecture independent, for them 'appearedin' and 'withdrawnin' have been added to the following tables:

  • SModCmd (history information for Commands)
  • Header
  • RpmTag
  • TypeMember

One can notice that, for type members, there could be a separate table implementing its N-to-N relation with the Architecture table, but our opinion here is that if anyone wants to introduce and take into account such table, the sql queries will become too complicated. So it's better to simply have TMaid field in TypeMember table (unlike interfaces, constants and other elements, creation of several records for the same type member assigned to different architectures will not cause the data growth in other tables, since no table contains references to TypeMember).

History information from the tables mentioned above is used by the scripts in order to generate files corresponding to the given LSB version (see below). 'appearedin' and 'withdrawnin' have been added to SubModule and SModLib tables only to provide human with history information.

IntStd table also has ISappearedin and ISwithdrawnin fields which are used to determine to which Standard interface is assigned in particular LSB version. These fiels should not be rteated as indicators of interface inclusion in LSB itself.

As for the SubModule table, there is one more field named 'SMmandatorysince', that shows when the module became mandatory (non-optional, non-trial-use).

Recovering Version History

In all the tables, 'withdrawnin' and 'appearedin' fields have been populated based on specdb CVS history. However, our goal was to get the full history information for 3.0 and 3.1 versions only. For earlier versions, some information can be missing because, in the past, when an element became excluded from the statndard the appropriate record was physically removed from the database; we have not recovered such records for versions prior to 3.0. Moreover, a lot of tables (Module, all concerning Classes) appeared only in LSB 2.0 and it is hard to compare the DB contents between early LSB versions. Nevertheless, if an element appeared in an earlier version and is still included (with the same properties), 'appearedin' field for this element contains valid value (including the cases of '1.0').

The bottom line is that it is not correct to generate LSB deliverables from the current database for LSB versions earlier than 3.0 because they may be incomplete due to the missing records that were physically removed. As for 3.0 and 3.1 versions, they contain full history information and the data in DB is enough to generate all the deliverables (specification, SDK, *chk).

Getting Rid of *stdstatus Fields

Since for every element we know when it appeared and when it was withdrawn, we don't need '*stdstatus' fields any more. More precisely, there is another way now to know if an element is 'Included', 'Excluded' or 'Withdrawn'. However, for some elements, *stdstatus field could have specific values (SrcOnly, Future, etc.). Now the separate fields indicate such properties. Formally, all 'SrcOnly', 'Future' and other non-'Included'elements are excluded from the specification (except 'Conly' types). The full list of the new fields:

  • Constant.Csrconly
  • Header.Hsrconly
  • Interface.Isrcbin
  • Type.Tsrconly
  • Type.Tindirect
  • Type.Tconly

As for the 'Future' status, elements table have *candidatefor field that is NULL by default but can contain LSB version where the element will probably appear. This field also has varchar type and 'Unknown' value can be set for it. In any case, if this field is not NULL, this means that the element is planned for future (has 'Future' status).

Elements' LSB Status Management

We strongly recommend not to drop records from the database when an element becomes excluded, since it will break the historical data. Instead of this, one should simply change element's 'withdrawnin' field and set it to an appropriate value.

For elements that were once in the LSB, then were excluded, then appeared again we suggest to have several records in the db. For example, if an element foo was included in 2.0, excluded in 3.0 and included in 3.1, there should be two records for it in the appropriate table:

name appearedin withdrawnin
foo 2.0 3.0
foo 3.1 NULL

After some discussions we came into agreement that this way is more preferable than to add additional field that will keep the list of versions where the element was excluded (since this solution would make queries too complicated and their execution time more long).

The same manipulations should be performed when some properties of an element are changed in a new LSB version (for example, the value of a constant, an rpm tag name, etc.) - instead of directly changing the value in the appropriate table, one should mark the record with previous value as withdrawn and add the record with the new value. (Surely, this doesn't concern the situation when the changes are bugfixes - in this situation the values should be changed directly).

LSB Version-Dependent File Generation

All generating scripts (that create specification, headers, etc.) now are provided with information about LSB version for which the files should be generated. All makefiles that call such scripts have been modified; they take the LSB version from a file. For lsbspec module, such files are version.* files from LSB subdirectory. In other modules, new 'LSB_VERSION' files have been created for this purpose.

To generate files corresponding to a certain LSB version, one should simply type in the version in these files (now they are filled with '3.1'). Since 'appearedin' and 'withdrawnin' fields are strings, the simple comparison is performed between the values of these fields and the version provided by the user. The comparison is done by string values, so one can specify a version higher than all existed. In this case the elements will be collected that have ever been added and have NULL in withdrawnin field (usually this means the most recent version of LSB).

Personal tools