[Replication] indexing the entryCSN and entryUUID attributes

[Kiran Ayyagari <ay...@gmail.com>]

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)


    2. entryUUID index

       Am thinking of adding a *system* level index on entryUUID AT for the following reasons

       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 ;) )

    wdyt?

Kiran Ayyagari

Re: [Replication] indexing the entryCSN and entryUUID attributes

[Alex Karasulu <ak...@gmail.com>]

On Sat, Mar 21, 2009 at 6:21 AM, Kiran Ayyagari <ay...@gmail.com>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)
>

100% agree.  I've suggested this several times in the past but we had
nothing in place to build the system index.


>
>   2. entryUUID index
>

100% agree again.

Thanks,
Alex

Re: [Replication] indexing the entryCSN and entryUUID attributes

[Emmanuel Lecharny <el...@apache.org>]

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
www.iktek.com
directory.apache.org