Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Received-SPF: pass (athena.apache.org: domain of elecharny@gmail.com
 designates 209.85.212.180 as permitted sender)
Message-ID: <52094759.8060709@gmail.com>
Date: Mon, 12 Aug 2013 22:36:41 +0200
From: =?UTF-8?B?RW1tYW51ZWwgTMOpY2hhcm55?= <elecharny@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
 rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: Apache Directory Developers List <dev@directory.apache.org>
Subject: [Mavibot] Generic usage
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Hi guys,

we have some kind of bad usage of generics in Mavibot, and I'm trying to
get it fixed.

The pb lies in the way we handle the data we store in a BTree. A BTree
has pages (Nodes and Leaves), and those pages hold elements which can be
other pages, or values. Values can themselves be simple or multiple (and
we could consider that a simple value is just a specific cas of a
multiple value). We also store the pages and values either in memory or
on disk, so we may have references to physical storage in the second case.

This is not quite simple to mimic using generics.

Let's sumup all those things :

A Node stores Pages (either Nodes or Leaves), which may be dereferenced
if they are not in memory.
A Leaf stores Values which may be simpe or multiple, and themselves
could be dereferenced if they are not in memory.
Multiple values are stored in a BTree<V, V>, where V is the value's type
(in fact we *never* store the value, we just store the key.

At this point, we can define the generic we want to use and the classes
to implement those constraints

ValueHolder :
-------------

Defines a value stored in memory.

MultipleValueHolder :
---------------------
 o Defines a value where V is a multiple value stored in a BTree<V, V> :

    MultipleValueHolder<K, V> extends ValueHolder<K, BTree<K, V>>

 o Stored in memory

ReferenceValueHolder :
----------------------

This is a simple value stored on disk. We may have to read it from the
disk, but t may be present in memory too.

    ReferenceValueHolder<K, V> extends ValueHolder<K, V>


ReferenceMultipleValueHolder :
------------------------------

 o Defines a value where V is a multiple value stored in a BTree<V, V> :

    ReferenceMultipleValueHolder<K, V> extends ReferenceValueHolder<K,
BTree<K, V>>

 o Stored in disk, so may be dereferenced if it's not present in memory

Page :
------

A Page can be either a Node or a Leaf.

    Page<K, V>


Node :
------

Stores references to other pages (Node or Leaf)

    Node<K, V> extends Page<K, V>


Leaf :
------

Stores references to values (either simple of multiple, either in memory
or dereferenced)

    Leaf<K, V> extends Page<K, V>


ReferencePage :
---------------

When a page is not present in memory, it can be loaded from disk.

    ReferencePage<K, V> extends Page<K, V>

ReferenceNode :
---------------

A Node which is stored on disk

    ReferenceNode<K, V> extends Node<K, V>

ReferenceLeaf :
---------------

A Leaf which is stored on disk

    ReferenceLeaf<K, V> extends Leaf<K, V>


Now, we never know in advance if we will store references or memory
values into a leaf or a node, at least when we create a BTree. The BTree
will use references whan it's managed.

At this point, I'm a bit stuck and I'm facing some issue when dealing
with multipleValues, and get a Classcast expression when trying to add a
new value. I'm working on it though...

-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com