IOPC 2 managed to unify the POLiTe 2 and IOPC libraries into one solid, flexible and extensible platform. Thanks to its well-designed interface and modular architecture, the library can be easily customized, enhanced and used. Its ability to integrate with IDEs and its reflective features provide the developers with almost transparent object-relational mapping functionality.
If we compare the table from the section called “Library comparison” against final IOPC 2 implementation described in the last two chapters, we may see changes, mostly improvements in many of the listed areas:
| POLiTe | POLiTe 2 | IOPC | IOPC 2 | |
|---|---|---|---|---|
| Transparent usage | - Macro descriptions | - Macro descriptions | + Uses Open C++ | + Uses GCCXML |
| Supported mapping types | - Vertical | - Vertical | + Vertical, horizontal, filtered, combinations | + Vertical, horizontal, filtered, ADT, combinations |
| Associations between objects | + Simple reference and relations - one-to-many, many-to-one, many-to-many, chained | + Simple reference and relations - one-to-many, many-to-one, many-to-many, chained | +/- Simple reference and reference list | - Only simple reference |
| Caching | - Simple object cache | + Advanced caching features. | -- Simple object cache, no locking | + Advanced caching features (same as POLiTe 2). |
| Querying | C++-like syntax, combining queries | C++-like syntax, combining queries | C++-like syntax, combining queries | SQL syntax, class metadata embedding |
| Read-only database / existing schema support | + | + | - | + |
| Library architecture | - Monolithic | - Monolithic | - Monolithic | + Modular, configurable |
| Supported databases | Oracle 7 (OCI 7) | Oracle 7 (OCI 7) | Oracle 8i (OCI 8) | Oracle 10g (OCI 10) |
| Multithreading support | - | + | - | + |
IOPC 2 was designed with emphasis on modularity. IOPC 2 doesn't provide only object-relational mapping services. It consists of a set of libraries which can be used in one of four configurations - an object persistence library, a database access library, a reflection library and an all-purpose library providing some useful tools. The database access library can be further customised with separate database drivers.
The reflection library represents a unified interface which allows developers to inspect the structure of the reflection-capable classes at run-time. It offers some of the features which are incorporated into reflective languages like Java or C#. To get the metamodel description IOPC 2 uses GCCXML, which represents a more reliable solution than OpenC++ used by IOPC.
Object-relational mapping capabilities of the original IOPC library has been enhanced by one additional mapping type - the ADT mapping. ADT mapping is a result of discussion on object-relational databases presented in this thesis. It demonstrates how their features can simplify the development of an object-relational layer. IOPC 2 also retained the ability to work with existing or read-only database schemas.
Although the IOPC 2 library covers many of the needs developers may pose on an object persistence library, there is a lot of room for improvement and future enhancements. A major issue of this library is the lack of a persistable data type representing a list of references. To express various kinds of associations between persistent objects, POLiTe libraries used relation objects as described earlier in the section called “Metamodel and object-relational mapping.”. POLiTe libraries also allowed to use a simple reference to model the one-to-many relation. IOPC replaced the concept of relation objects with the persistent references and reference lists. Unfortunately, the reference lists were almost unusable, so they were removed from the IOPC 2 implementation and remained to be implemented in the future. The future implementation should also use some of the ORDBMS features like references or arrays to store these lists in the database. Reintroduction of the relation objects may also be possible.
This leads us to the second, smaller, issue - IOPC 2 aside from ADTs doesn't use other ORDBMS features. There are many other ways how to enhance functionality of the library in this area. Other areas may also improved - for example the reflection can be given the ability to describe and invoke methods.
IOPC 2 also lacks proof of concept - a real-life or real-life-like application that would demonstrate the library usability for the purpose for which it is designed. There should be both - web-based as well as a thick client application. Such test would probably reveal other issues or misconceptions which may result in additional requirements on the library. For example the web application requirements would surely include a connection pool facility to speed up the connection creation process. Similarly, another non-Oracle database driver could be implemented - support for a lightweight in-process database like SQLITE[31] would be interesting.