eXtremeDB’s Type-safe API
Eliminate Database Corruption
The eXtremeDB native API is type-safe: errors in data-typing are caught at compile time, to eliminate database corruption.
Embedded database function libraries offer benefits including convenience, portability and productivity, but the manner in which they are constructed and used leads to bugs. These application programming interfaces (APIs) are nearly always data structure ignorant — they handle data without knowing its type. This severely limits the compiler’s and runtime’s abilities to perform any validation, greatly increasing the likelihood of programming mistakes slipping through QA.
McObject’s eXtremeDB database system takes a dramatic step forward by introducing a type-safe API. In its native API, eXtremeDB offers a limited set of static functions for basic tasks such as opening and closing the database. However, most of the functions for interacting with a given database design are generated when the schema is compiled using eXtremeDB’s mcocomp database definition language (DDL) compiler utility.
Because these functions “know” the data type they are expected to handle, assignment errors are caught when the application is compiled – rather than after release, when addressing the problem is typically much more expensive.
This approach has the additional benefit of creating a more intuitive, easier-to-learn programming interface. The eXtremeDB-generated interfaces are more readable and self-documenting than are functions from a static interface designed for use with an infinite variety of database designs. The developer knows exactly what operation is being carried out and on what data, and the project enjoys a greatly reduced risk of introducing destructive bugs.
Yet another bulwark against database corruption is eXtremeDB’s set of debug libraries. In its source code, eXtremeDB developers have incorporated different levels of sanity checking that help application developers find and eliminate errors in the use of the eXtremeDB API. eXtremeDB ships with two sets of libraries: 1) a fully optimized version with the sanity checks disabled and, 2) a full debug version with all sanity checks enabled. Naturally, the sanity checks require additional code size and execution clock cycles. Source code licensees can build additional sets of libraries with different levels of debugging. The sanity checks ensure that developers are using the eXtremeDB API in the intended way. For example, it gracefully traps an attempt to use a transaction handle after the transaction has been closed (committed or aborted). The optimized run-time will simply emit a fatal error. When a team has successfully compiled the systems, and all QA has passed with the debug libraries, the systems can be relinked with the optimized run-time to minimize code size and restore precious clock cycles, with a high degree of confidence that all database-related application defects have been found and remediated.
In addition to proactively preventing database corruption through the use of a type-safe API and debug libraries, the eXtremeDB run-time can also be configured to calculate a page-level CRC checksum and to validate the checksum whenever a page is fetched. This can be used to detect unauthorized tampering of the database content, e.g. an attempt to override digital rights management or other database access security.
Read about eXtremeDB APIs in our online documentation.
Interested in a side-by-side code comparisons of eXtremeDB’s type-safe API and a traditional “static” database interface? We recommend the article Self-Diagnostic APIs: Software Quality’s Next Frontier in Linux Journal.
Additional information on the concept of a type-safe API, and eXtremeDB’s implementation, can be found in the EE Times article, Toward Self-Diagnostic APIs for Embedded Systems.
Learn more about the eXtremeDB family.