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

Re: collections / ODMG / schema / indexes



On Thu, 27 Jan 2000, Davide Mora wrote:
> COLLECTIONS.
> What i have to use? Java's Vector, Hashtable or the
> Dx* equivalent? (everything work fine with both)
> What is the difference? And why there is this Dx
> "clone"?
DxLib is a port of DmPack2 which is a C++ collections library that we heavily
use for WipeOut. When we started ozone there was no Java collection library.
So we decided to port DmPack2 because everybody here was familiar with the
DmPack2 API.

The main difference between Java2 collections and DxLib is the
iterator/enumerator interface. In fact, they provide nearly the same
functionality.

Since all these collection classes are "simple" in-memory implementations, it
makes no difference which collections you use for ozone.

However, to store huge collections in ozone we need special
collection implementations that split up into several parts that can be
loaded/stored independently. Something like DxDiskHashmap. Volunteers?

> 
> ODMG.
> I took a look to the 0.3.3 source code, the classes of
> the omg package are empty, when will be available a
> working version of this classes? Will be ODMG 2.X or
> 3.0?
Yes, they are empty ;) I had to finish the transaction interface first because
this is needed for ODMG. Next I will try to make XA support available. Afterward
I will work on ODMG.

The problem of ODMG 3.0 is that the semantic of the methods is not clear from
the Javadoc. I will have to buy the spec first. Or is anybody out there
familiar with ODMG 3.0?

> 
> SCHEMA.
> How Ozone store the objects? Use a schema or just
> serialize the objects?
> If there is a schema, it's possible browse it?
Today clusters of objects are just serialized to files. However, this is not
required by ozone. It should be possible to use tools like Castor which creates
a RDBMS schema as the store back-end of ozone.

> 
> INDEXES.
> There are plans for add indexes to the objects's
> members? Collections it's good... but are
> time/resource consuming, indexes can speed up the
> search.
When you store database objects (more precise their proxies) in a DxTreeMap or
DxHashMap, then the collection *IS* the index. If the collection (index) object
itself is in the cache already, then the index search runs at in-memory
(maximum) speed. After you have found the proxy in the collection it is up to
the ozone kernel to load the associated object in the cache as fast as possible.

In other words: there is no need for an explicite index because there is no
Java API to use such an index other than collections. 

OQL is another story. If someone will implement OQL for ozone someday, he/she
will have to add some kind of indexes, of course. Personally I think OQL is not
a must have.


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