SDO for C++ Wish List
There are many additions which could be made to the Tuscany SDO C++ version to improve the functionality and help with interoperation.
If anyone feels like tackling any of these, you are very welcome.
Improve get/set performance
DataObject frequently maps from Property to index, and this could be re-organized to avoid most of these. All the getter/setter routines are duplicated for char and prim, and need to be un-macro-ed.
improve storage performance
The allocation of space for property values could in most cases be dropped - its usually s fixed size element, and should have its own storage class to make things easier to understand.
Big Number handling
The ChangeSummary class holds the previous value of any property when it is changed. At present, for many-valued properties, it holds the entire list as it was before an addition. This could just keep a record of valued properties, it holds the entire list as it was before an addition. This could just keep a record of the changes, and only save the old list when serializing.
Verify create/delete against java serialized forms
I know that create/deletes are elements in C++, but what are they in java?
Open type name clash resolution
Open types - must support name clashes. Each instance may have different indices for same prop. Need to support open property of type data object, so get its type. Need to validate the type system from the data factory.
implement ReadOnly Properties
Read Only properties were omitted from the first drop due to time constraints.
implement Opposite Properties
Opposites. Opposite properties were omitted from the first drop due to time constraints.
implement get/setXMLVersion() get/setSchemaLocation() get/setNoNamespaceSchemaLocation( )
XmlDocument. The support of XMLDocument is very limited as XML parsing information is not made available by libxml2. We have toi investigate a better way of supporting XmlDocument, or agree not to. This activity may drop out of the work on stax.
Use of STL string
[Geoff.email@example.com is looking at this one] The current API used char* strings, and internally does a lot of strlen, new char type stuff. This could be replaced either by std::string, or by a SDO string class which takes std::string or char* construction. This would make SDO more robust against memory leaks, and possibly faster.
Type safe API
SDO for C++ uses the dynamic API (getString("name")). There is a prototype example of how we might develop code generation to generate the typesafe API for data objects, by containing a data object in a class which has methods such as setName() etc. This is very preliminary, and Im not even sure of the added value. It would be really good if anyone could take it and tell me if the benefits of type safety outweigh the overhead of having generated code.