directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <>
Subject Re: [Replication] indexing the entryCSN and entryUUID attributes
Date Sat, 21 Mar 2009 14:41:54 GMT
Kiran Ayyagari wrote:
> hello guys,
>       Currently the entryCSN and entryUUID attributes do not have a 
> index.
>    1. entryCSN index
>       I believe that the entryCSN should have a *system* level 
> index(we can avoid any
>       issues related to letting the user configure this index ), cause 
> it is crucial for determining which
>       entries needs to be served for each client( a.k.a consumer ) and 
> peer( a.k.a producer)
Absolutely. But we have to define the MatchingRules for this index.
>    2. entryUUID index
>       Am thinking of adding a *system* level index on entryUUID AT for 
> the following reasons
We have to. The EntryUUID is the unique identifier for an entry. Even 
the DN is not, as you can move an entry, unlike the UUID, as it does not 
change when you move the entry.
>       1. There is a situation where some entry(ies) needs to be 
> deleted only using entryUUID.
>          At the moment there is no method in CoreSession interface 
> which takes a entryUUID to delete (similar to
>          CS.delete(LdapDN) ). This forces us to perform a search on 
> DIT and then do a delete after getting the entry.
>       2. We need not force users to configure an index for this AT ( 
> if the above said new method was implemented )
>       ( My brain fails to think about any other valid uses of this 
> entryUUID *system* index other than for deleting an
>         entry ;) )
We need it while doing conflict resolution (like when modifying an entry 
which already exists locally)

Btw, we also need to make the ObjectClass index a system index (ie we 
should not force the user to create it. The very same for the 
hierarchical index).

The only reason we have them in the config file is that we need to 
configure the cache for them. That does not mean we should not create 
them if they don't exists in the config file...

cordialement, regards,
Emmanuel L├ęcharny

View raw message