[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ODMG 2.0

On Sat, 21 Aug 1999, Zvi Avraham wrote:
> Falko Braeutigam wrote:
> 
> > On Wed, 18 Aug 1999, you wrote:
> > > Hi all,
> > >
> > > Is Ozone compliant (or will be compliant) to ODMG 2.0 Java binding  ?
> > Oh boy, that's a difficult question!
> >
> > Some time ago we discussed this already here on the list. The conclusion was:
> > Yes, it would be nice to have but it is not one of our main goals.
> >
> > I do not like ODMG 2.0 because it is called and should be a standard but it
> > isn't. In no meaning of the word. I know, these are very heretical words but is
> > is the truth in my eyes. Yes, I have the ODMG spec on my desk and I try to
> > follow their Java binding but what is this for, if we do not implement the
> > entire spec? But we do not want nor we are able to implement all parts of the
> > spec.
> 
> I don't like OQL too (but my boss like to have standard query language like SQL
> :-).
Yes, I know. It is great to have an interface like SQL for all products. But
there is one big difference between relational databases and the OO paradigm.
RDBMSs are based one a simple, closed, strong theory - the OO paradigm is, as
the name implies, just a paradigm, no strong theory! There is nothing like the
object-oriented algebra. And this is the weakness and the absolutly power of
the OODBMSs. Each product has its own advantages and disadvantages. And each
product perfectly meets the needs of some applications.

Why do we need something different from RDBMSs? Because they are (based on a
strong theory) to static to be able to handle the needs of object-oriented
systems! So, if we really want to close the impedance mismatch between
languages and databases, then we will get new database interface for at least
every new language or language version - no chance for a language independent
standard.

> In my opinionOQL can be optional in ODMG 2.0 spec. The beauty of Object
> databases that whole development
> can be made in one language and OQL break it.
> 
> > We do not want it because (for example) OQL is part of the spec. The
> > vision behind ozone is to find a way to do the entire application development
> > in Java, not just the business logic and another part in a absolutely
> > incompatible language/system. And now we do not want to implement OQL in ozone
> > just to be "ODMG compliant".
> >
> > And we are unable to implement all of ODMG because they have such things in
> > their spec that are simple incompatible to ozone. Example: [page 234, "Object
> > Persistence"] - "In the Java binding, persistence is not determined at object
> > creation time." Hmmm.... what can I say? Most of the ODMG members are C++ db
> > guys with page servers or at least decentral activation. Persistence by
> > reachability is ok for them. ozone has a Java based central activation
> > architecture. I cannot see a way around the createObject() calls. So we are
> > simply not able to implement ODMG with ozone.
> 
> Can't createObject() be embedded into constructors of persistent-capable
> classes,using OPP tool ?
Maybe, but this is just an example. What I want to say is, often there is
just one line of text in the ODMG spec that describes the "standard" for things
like garbage collection. Can you imagine that? There are so many things to
specify than just to say "objects may be automatically removed from the
database if that object is neither named nor referenced...". It _may_ be
removed ?!?! Do you see the problem? You cannot write portable code, even if all
products would be 100% ODMG compliant.

> 
> > Of course, we could say so. And it would not be "really false" but what is a
> > standard good for, if all implementors can say they are compliant but in real
> > world it is not possible to run the same code on different platforms? In my
> > eyes, that's the case with ODMG.
> >
> > Am I wrong? Do you really need ODMG Zvi?
> 
> I personally don't need ODMG, but it will help to convince my management:)
> I testing Ozone and ODBMSes at all, for 2 projects:
> 
> 1. My own XML-based project, hopefully it will use Ozone-XML and there is no need
> in ODMG
> compliance (although ODMG now have XML Data Servers interest group).
> 
> 2. SupportNow Server (project at work), it's data model is collection of Support
> Calls, and calls
> from different applications have different structure (it's fully customizable by
> end-user, and even not
> known at development time). The server have CallDB interface for storage. I have 2
> implementation
> of this interface: one using filesystem and serialization, and other using
> JDBC/SQL.
>   Now I trying to convince management to write third implementation of storage
> interface, using
> ODBMS, because it perfectly fit our requirements (complex data model and
> relationships between
> objects). For my boss ODMG standard tells vendor independence, so we can develop
> one version
> with Ozone, and in later version switch to ObjectStore or to Oracle8i with
> Object-Relational
> mapping, etc ... But from your answer I understand that ODMG compliance is fiction,
> right ?
> Is today possible to write Java application that without modification will work,
> say, both with POET
> and ObjectStore ?
As far as I know ObjectStore is not ODMG compliant.... !

> Falko, let me know, when single-VM version of Ozone will be ready, and I'll try to
> write storage
> interface using Ozone.
There are still some problems but it works so far. I will release it tomorrow.

Zvi, can you help with the ozone based implementation of the cocoon cache
system? I know, you are more familiar with cocoon than I.

> 
> Zvi
-- 
______________________________________________________________________
Falko Braeutigam                         mailto:falko@softwarebuero.de
softwarebuero m&b (SMB)                    http://www.softwarebuero.de