This article describes the principles guiding the Polyhedra® development process, to ensure customers can field-upgrade their systems with new releases of our software with minimal disruption. It also discusses compatibility between different members of the Polyhedra family of database management systems.
A copy of this article in PDF form is attached to the bottom of the article, for ease of printing and offline viewing.
Polyhedra database systems have often been used in long-lifetime projects, and this imposes particular requirements on our customers - and thus indirectly on the support we offer and the compatibility between different releases of Polyhedra. To assist our customers better support their customers, particularly in High-Availability systems where taking down a 5-nines system for 5 minutes for an upgrade uses up almost the full amount of permitted downtime for a year, Polyhedra have developed a set of compatibility principles that guide us when developing new releases of our products. These principles can be broken down into two main categories: heterogeneity and forward compatibility, but there is also a degree of interoperability between different Polyhedra products.
These release interoperability principles were introduced in 2002 at the time of the introduction of Polyhedra 4.2. They refer to the interoperation of Polyhedra releases 4.1 onwards, but for the benefit of customers who had deployed systems based on Polyhedra 4.0 or earlier, we supply bridge components enabling a degree of interoperability between Polyhedra 4.0 (and earlier) systems and systems using versions from Polyhedra 4.1 onwards.
There are four members of the Polyhedra family of Database Management Systems. Three of them, Polyhedra32 IMDB, and Polyhedra64 IMDB, are in-memory database systems (IMDBs), which keep the working copy in of the database in RAM, whereas Polyhedra Flash DBMS keeps the database in a file (assumed to be on a flash-based filing system) with an in-memory cache to improve performance. The Polyhedra Flash DBMS product is designed for small footprint systems, while the IMDB products are more targeted toward performance and can be set up in fault-tolerant configurations for high availability. The final member of the family is Polyhedra DBI, which acts as a Polyhedra server but keeps its data in a foreign database system (accessed via its ODBC driver).
All the products use the same client-server libraries - and thus the use the same client-server protocol and can interoperate freely at that level. In addition, Polyhedra32 IMDB and Polyhedra64 IMDB can read each other’s database files - though of course due to the in-memory nature of these products, if a Polyhedra32 IMDB or Polyhedra64 IMDB database file is taken to a system with less (addressable) memory than there was on the system that created the file, it may not be possible to load the file, regardless of whether the same Polyhedra product was being used. In addition, Polyhedra Flash DBMS can used a database file produced by Polyhedra32 IMDB or Polyhedra64 IMDB to populate a new Flash DBMS database.
In this document, a term such as ‘a Polyhedra server’ refers to the database server component of any member of the Polyhedra family of products, while the ‘Polyhedra IMDB’ is used to refer to both the Polyhedra32 IMDB & Polyhedra64 IMDB products. Except where explicitly mentioned or as covered by the previous paragraph, the rest of this document refers to the compatibility of different releases/platforms of a particular Polyhedra product, rather than between different members of the product family.
Homogeneous systems are made up of similar components. Heterogeneous systems use a mixture - so different components may be running different versions of an operating system, or different operating systems, or be running on hardware architectures (with different endianisms, for example).
(This section does not apply to Polyhedra DBI.)
Firstly, a Polyhedra database file is position-independent; it does not have to be stored at a particular place in the filing system, nor have a particular name. When the DBMS starts up, you simply tell it (via a command line option, or via a configuration file) which file to use; while running, named snapshots (containing a copy of the schema and all persistent data that were present in the database at the time the snapshot was started, and a copy of the running CL where applicable) can be generated, which can then be renamed and/or saved away where you choose. This makes it easy to generate backups, revert to a backup file, and copy a saved database from one machine for use on another machine. Additionally, a database file is portable: it contains information regarding byte ordering, etc., so it can be used on a machine with a different architecture. Thus, a database file generated on, say, a Windows machine can be used as a seed database on a PowerPC running Linux, OSE or INTEGRITY, despite the differing endianisms (provided only that there is enough room to hold the database in-memory, when using one of the IMDB products).
When client and server are on the same machine or on compatible machines, the information transferred between them uses native byte ordering and number formats, for efficiency. Where there is a mismatch, there is enough information in the protocol to allow appropriate conversions to be performed automatically. Thus, those writing client applications do not have to worry about converting binary representations of values; a client running under Windows or Linux, say, on x86-compatible hardware, can readily interrogate a Polyhedra database running on a PowerPC or ARM computer, despite the endianism mismatch between the x86 and PowerPC architectures and the floating point mismatch between x86 and ARM. (ARM processors are typically operated in little-endian mode, but use ‘mixed mode’ for floating point values.)
(This section does not apply to Polyhedra DBI.)
For total flexibility, Polyhedra IMDB products allow a standby server to be operating on a different operating system and/or architecture to that used by the master - so a Windows machine can be running the standby for a database in a server running on a PowerPC, for example. While this is unlikely to be a standard configuration in practice, it can help during the development phases of a system where there may be a shortage of the target boards - and it can also help when upgrading in the field, if the replacement boards are ARM-based rather than PowerPC-based, say.
Polyhedra IMDB products also allow read-only replicas to be running on a different architecture and/or operating system to the server containing the database that is being replicated; a Windows desktop machine can thus be used to replicate a database held by a low-powered embedded device, and can allow complex queries to be performed without putting a strain on the embedded device. (At present, Polyhedra Flash DBMS does not support replica configurations.)
When upgrading a complex system with many boards, or upgrading part or all of a site consisting of a number of systems that can interoperate, it is important that the upgrades can be done smoothly, with minimal or no downtime. We therefore ensure a degree of interoperability between releases of a Polyhedra product, either directly or via bridge components:
· Old (already-built) clients can connect to the new server
· New clients can connect to older servers, and use those features they provide. (When using ODBC, client applications can interrogate the database to find out the release information and to determine which features are implemented.)
· New servers can read database files written by the previous release of Polyhedra
· New servers can act as standby to a master running the previous release of Polyhedra
(by ‘previous release’, we mean the previous major release of Polyhedra - so Polyhedra 8.6 can read a Polyhedra 7.0 database file, for example, as well as all releases in between. In practice, support for even earlier releases is usually provided, but in some cases it may be necessary to perform an upgrade from a very-old release in ‘stages’. Note also that as the different Polyhedra families share the same code base, they share the same version numbering scheme, and the versions are produced in step.)
Thus, in a simple system all you need do is stop the Polyhedra server, upgrade the DBMS software, and on restart the new server software will accept the old database file even if the formats have changed. (Of course, the database will in future be written out in the new format, so it is always sensible to take a back-up copy of the old database for safety.) In the unlikely event that it is necessary to install a bridge component to allow older clients on other machines to connect to the new server, the Polyhedra release notes will make this clear.
(There is one caveat: sometimes new keywords are added to SQL or CL, which can cause problems for an application if an old database uses one of these new words as a table, column, view or index name. if the problem is with a clash with a newly-added SQL keyword, then it may be enough just to ensure that the SQL script files and all SQL embedded in the application code uses the standard SQL convention of enclosing the problem names in double-quote marks. An alternative approach may be to dynamically update the schema to use non-clashing names prior to upgrading the Polyhedra software, and altering the application code to match.)
In a fault-tolerant, multi-machine or multi-board scenario – for example if upgrading a rack system consisting of multiple line cards running client software and a pair of control cards operating in a hot-standby configuration – you can simply take down the standby, upgrade the Polyhedra software and bring it up again as standby, and then promote it to master; the old master can now be upgraded and restarted as standby. The line cards can be upgraded at leisure, before or after upgrading the master (unless the new application software takes advantage of new features in the Polyhedra software, in which case the line cards should be upgraded after the server software on the control cards). If running a complex site with many different systems, platform and release interoperability means that overall the systems may be running a wide variety of different releases of Polyhedra, on a number of different platforms.
To ease application development, we try to ensure that the client APIs are upwards compatible at source level, so usually applications can simply be recompiled without modification and then relinked with the new libraries. We do not envisage any functional enhancements to our client APIs that would require more than minor changes to the application code (though more significant changes to the application may be needed to take full advantage of the enhancements.)
 Polyhedra32 IMDB was the original member of the product family, and hence is often referred to as ‘the’ Polyhedra DMBS or the ‘standard’ product. The Polyhedra32 IMDB designation is used in this article for the original product, for clarity.