Thanks! Your explanation answers about 1/2 the questions floating around
my head. :)
RobK
--------
Good questions! ;)
IMO it is not possible to swap between different ODMG databases without
changing to much code no matter if they "fully ODMG compliant" or not. For
example Objectivity, the only commercial OODBMS that I have a license for,
claims to support ODMG. In fact, the database classes have to extend a special
base class an all method have to call a fetch() method. Both is explicitely
ruled out by ODMG.
And, the actual API is just one part of the ODMG spec. Another (very
important) part is the definition of the underlying object model. This part is
way to unrestricted in the current version 3.0. For example, the ODMG object
model assumes that objects are activated on the client. (for historical
reasons, I think) but it's not strickly defined somewhere. ozone is based on a
single instance architecture where objects live inside the server. This
difference is very important for the application architecture because it
influences performance and transactional behaviour but ODMG is completely
unaware of this.
However, even if it does not allow to re-use 100% of the code, programming
against the ODMG interface makes it easier to port applications (even more if
you keep in mind the above mentioned restrictions of ODMG) and to re-use the
knowledge of the programmers.
The ozone ODMG interface is there and it works. It tries to be as ODMG compliant
as possible. I don't know how it works for real world applications. So any
experiences are welcome. ;)
Falko
--
______________________________________________________________________
Falko Braeutigam mailto:falko@smb-tec.com
SMB GmbH http://www.smb-tec.com