[apacheds] About the search result enumeration order

[Trustin Lee <tr...@gmail.com>]

Hi,

As you guys know, I'm implementing multi-master replication module for 
ApacheDS. The incremental replication is done, and now I need to implement 
full-DIT transfer protocol so that too old replication log entries can be 
purged to prevent from the storage expand without limit. (This is LDUP 
requirement AFAIK.)

So, I have a question on the order of search result here because of full-DIT 
retrieval; Does enumeration order guarentee that the child entries are not 
returned before their parent is returned? If so, we won't need glue entries, 
which is a kind of placeholder entries that will be replaced when the 
appropriate parent entry is retrieved. Otherwise, we will need them.

Trustin
-- 
what we call human nature is actually human habit
--
http://gleamynode.net/

Re: [apacheds] About the search result enumeration order

[Trustin Lee <tr...@gmail.com>]

Thanks for your quick response! :)
-- 
what we call human nature is actually human habit
--
http://gleamynode.net/

Re: [apacheds] About the search result enumeration order

[Alex Karasulu <ao...@bellsouth.net>]

Trustin Lee wrote:

> Hi,
>
> As you guys know, I'm implementing multi-master replication module for 
> ApacheDS.  The incremental replication is done, and now I need to 
> implement full-DIT transfer protocol so that too old replication log 
> entries can be purged to prevent from the storage expand without 
> limit. (This is LDUP requirement AFAIK.)
>
> So, I have a question on the order of search result here because of 
> full-DIT retrieval;  Does enumeration order guarentee that the child 
> entries are not returned before their parent is returned?

I think it depends on the search order and the composition of indices.  
The objectClass index will always list children after parents but don't 
bank on that.   Is there a specific order in which you need to get the 
entries?

> If so, we won't need glue entries, which is a kind of placeholder 
> entries that will be replaced when the appropriate parent entry is 
> retrieved.  Otherwise, we will need them.

I would go with glue entries.  Why? Because we cannot determine how a 
backend partition will return entries.  The algorithm is dependent on 
the implementation.  LDAP does not say an order is necessary.  Search 
controls which we have yet to implement could have been used here to 
control the order of entries being returned.  However this is not 
presently possible.

Alex