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

[Fwd: ODMG 2.0]








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
:-).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 ?

> 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 ?

Falko, let me know, when single-VM version of Ozone will be ready, and I'll try to
write storage
interface using Ozone.

Zvi