On Tue, 17 May 2011 17:59:58 +0530, Emmanuel Lécharny
<[email protected]> wrote:
On 5/17/11 2:18 PM, Rajesh Akkineni wrote:
On Tue, 17 May 2011 16:07:24 +0530, Emmanuel Lécharny
<[email protected]> 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. 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.
I thought there is no need to store the Rdn at all.
Is my observation wrong?
So why to save the RDN at all?
Because it *is* the entry's only name. If we don't save it, we have no
way to reconstruct the entry.
Why I am asking is, is there any other purpose for saving RDN?
No.
I suggest you step through the server code in debug mode, you'll see how
it works. Keep in mind it's a huge piece of code, so don't expect to
understand it inside out in a few days...
--
Rajesh Akkineni
