On Tue, May 17, 2011 at 3:49 PM, Emmanuel Lécharny <elecharny@apache.org> wrote:
On 5/17/11 2:38 PM, Rajesh Akkineni wrote:
On Tue, 17 May 2011 17:59:58 +0530, Emmanuel Lécharny <elecharny@apache.org> wrote:

On 5/17/11 2:18 PM, Rajesh Akkineni wrote:
On Tue, 17 May 2011 16:07:24 +0530, Emmanuel Lécharny <elecharny@apache.org> wrote:

On 5/17/11 12:30 PM, Prasanna Kumar G wrote:

     I am trying to understand ApacheDS code. I am not understanding the
Moving of Entry(Renaming the Dn). When Renaming Dn of an Entry, where are
you updating the child entries.
We don't. We store RDNs, not DNs.

But that RDN also not being used as the DN which is constructed in ServerEntrySerializer is not valid, and it isbeing overwritten in AbstractStore.lookup

ServerEntrySerializer :

    public Object deserialize( byte[] bytes ) throws IOException
        ObjectInputStream in = new ObjectInputStream( new ByteArrayInputStream( bytes ) );

            Entry entry = new DefaultEntry( schemaManager );

            // Read the Dn, if any
            byte hasDn = in.readByte();

            if ( hasDn == 1 )
                Rdn rdn = new Rdn( schemaManager );
                rdn.readExternal( in ); <============== Here we read the RDN.

The AbstractStore.lookup method just rebuild the full DN, using the serialized RDN and the position in the tree of this entry.

I am sorry(for being persistently stupid), I have seen the above code. But here is code from AbstractStore

   public Entry lookup(ID id) throws Exception {
       Entry entry = master.get(id);

       if (entry != null) {
           Dn dn = buildEntryDn(id);
           return entry;

       return null;
I see that the Dn is being replaced

The serialization/deserialization occurs a layer down. In the AbstractStore, we already have a deserialized entry, containing the RDN.

. And Rdn or Entry is not being used to get the Dn. Using ID and rdnIndex we are getting the Dn, and rdnIndex does not depend on anything we save in masterTable.
There might be a slight improvement here, as the DN is constructed using the RDN table, right. Please fill a JIRA for that.

Sorry but it was not clear to me what sort of improvement you were envisaging. Can you elaborate on that?