Use of storedObjects

The purpose of this document is to show how a different Persistent Storage Engine could be linked to Irf.

Would sO be OK for IRF ?

Is partial materialization available ?

Yes, thanks to the parameter DB.FLAT for the restore() method. When an object has been restored this way, its inner references can't be resolved, they first have to be restored with restoreMore(). With a trick (getOID() first), restore() can be called on this reference and completely restores the hierarchy from this point, because restoreMore() only rematerializes one level of indirections (same as restore() with DB.FLAT).

arrays ?

They are correctly handled by sO, they are even optimized, so that you can for instance index fields of classes stored within the array.

Vectors, Hashtables ?

At first, IRF was using regular Java Vectors and Hashtables. But efficiency matters made us switch to IrfHashtables and FeatureLists. Thus, we don't have to handle the regular classes anymore. But it may be nice to be able to use them with a different storage mechanism, so how does so manage with them ? First, both of them are handled, but it looks like there's a problem for the use we would make of them in IRF (Vectors used as values IN hashtables). Storing redefined Vectors (ie FeatureLists) in regular Hashtables isn't a problem. Redefining Hashtables seems to be: first drafts compile but crash at runtime.

Efficiency ?

Definitely very fast. A little overhead at the beginning and at the end, due to the DB management, but then it's nearly as fast as direct work in RAM.

Current State

An application managing an index in which Docs containing Des can be indexed with an IF class.

To Do:

All the files are available in the directory, they are: