Modifications to JDBM

[Emmanuel Lecharny <el...@apache.org>]

Hi Alex,

while modifying the server (directory), I had to modify the JDBM code to 
add a setter for the BTree class (setValueSerializer()), simply because 
I need to use a specail serialize, which takes a set of data in order to 
be able to create deserialized objects. The fact is that if we already 
have a file containing some data, the BTree ressucitate the 
valueSerialalizer from the file, using a standard deserialization process.

I think I can modify the RecordManager in order to create a new instance 
of the ValueSerializer, but I find this a little bit cumbersome.

Anyway, I just want to know if we can do this modification on the JDBM 
code base, if there is any chance that a JDBM 1.0.1 can be release, or 
if we simply have to fork the project and define it as a subproject of ADS ?

wdyt ?

Thanks !

-- 
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org

Re: Modifications to JDBM

[Emmanuel Lecharny <el...@apache.org>]

Alex Boisvert wrote:
> Hi Emmanual,
>
> Can you send me your patch?  I can do a JDBM 1.0.1 release based on it.
Sure ! I will try to see if we can find a fix for Alex problem (the 
getprevious issue).

Thanks !

-- 
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org

Re: Modifications to JDBM

[Alex Boisvert <bo...@intalio.com>]

Hi Emmanual,

Can you send me your patch?  I can do a JDBM 1.0.1 release based on it.

alex


On Wed, Apr 23, 2008 at 3:14 PM, Emmanuel Lecharny <el...@apache.org>
wrote:

> Hi Alex,
>
> while modifying the server (directory), I had to modify the JDBM code to
> add a setter for the BTree class (setValueSerializer()), simply because I
> need to use a specail serialize, which takes a set of data in order to be
> able to create deserialized objects. The fact is that if we already have a
> file containing some data, the BTree ressucitate the valueSerialalizer from
> the file, using a standard deserialization process.
>
> I think I can modify the RecordManager in order to create a new instance
> of the ValueSerializer, but I find this a little bit cumbersome.
>
> Anyway, I just want to know if we can do this modification on the JDBM
> code base, if there is any chance that a JDBM 1.0.1 can be release, or if we
> simply have to fork the project and define it as a subproject of ADS ?
>
> wdyt ?
>
> Thanks !
>
> --
> --
> cordialement, regards,
> Emmanuel Lécharny
> www.iktek.com
> directory.apache.org
>
>
>

Re: Modifications to JDBM

[Emmanuel Lecharny <el...@apache.org>]

Alex Karasulu wrote:
>
> BTW there's a nasty little bug in the JDBM Browser implementation that 
> was causing me a big headache with the Cursors.  
The problem is that the browser just move forward AFTER having fetched a 
tuple, not before. The semantic of these methods are : "fetch the 
current tuple, then move forward/backward"

This should be easy to fix.

-- 
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org

Re: Modifications to JDBM

[Alex Karasulu <ak...@apache.org>]

I think we should go ahead and fork then inform the JDBM peeps.  But the
fork should not change package names so when and if the JDBM peeps update
JDBM we can drop our fork if possible.  I hate to have to fork but what can
we do.  Just make sure you commit JDBM as is then apply your changes so we
can track what changes we've made to report back to the JDBM folks with
diffs from our repo.

BTW there's a nasty little bug in the JDBM Browser implementation that was
causing me a big headache with the Cursors.  It's really a bitch to deal
with but probably easy to fix in the JDBM code.  The browser once I create
one and start using it to advance in one direction requires to operations in
the reverse direction to start advancing backwards.  For example:

BTree may contain:
[1,1]
[2,2]
[3,3]

10 browser = btree.browse();
20 browser.getNext(tuple); => true with [1,1]
30 browser.getNext(tuple); => true with [2,2]
40 browser.getPrevious(tuple); => true with [2,2]
50 browser.getPrevious(tuple); => true with [3,3]

Notice lines 30 and 40 is where the direction change occurs and it requires
two getPrevious() operations to move one tuple back.  The same problem
exists if we switch directions in the opposite way.   So this fork gives us
a chance to fix this issue.

Alex

On Wed, Apr 23, 2008 at 6:14 PM, Emmanuel Lecharny <el...@apache.org>
wrote:

> Hi Alex,
>
> while modifying the server (directory), I had to modify the JDBM code to
> add a setter for the BTree class (setValueSerializer()), simply because I
> need to use a specail serialize, which takes a set of data in order to be
> able to create deserialized objects. The fact is that if we already have a
> file containing some data, the BTree ressucitate the valueSerialalizer from
> the file, using a standard deserialization process.
>
> I think I can modify the RecordManager in order to create a new instance
> of the ValueSerializer, but I find this a little bit cumbersome.
>
> Anyway, I just want to know if we can do this modification on the JDBM
> code base, if there is any chance that a JDBM 1.0.1 can be release, or if we
> simply have to fork the project and define it as a subproject of ADS ?
>
> wdyt ?
>
> Thanks !
>
> --
> --
> cordialement, regards,
> Emmanuel Lécharny
> www.iktek.com
> directory.apache.org
>
>
>