On 5/17/11 2:38 PM, Rajesh Akkineni wrote:
On Tue, 17 May 2011 17:59:58 +0530, Emmanuel Lécharny
<elecha...@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
<elecha...@apache.org> wrote:
On 5/17/11 12:30 PM, Prasanna Kumar G wrote:
Hi,
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 ) );
try
{
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);
entry.setDn(dn);
return entry;
}
return null;
}
I see that the Dn is being replaced
s/replaced/reconstructed/
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.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
