Hi Emmanuel,
On Sun, May 9, 2010 at 6:42 PM, Emmanuel Lecharny elecha...@gmail.comwrote:
...
As soon as you consider that a delete operation will need to update all the
index the deleted entry uses, you see that you can benefit from having such
reverse index : you don't have to grab the entry
On 5/13/10 8:08 AM, Alex Karasulu wrote:
Hi Emmanuel,
On Sun, May 9, 2010 at 6:42 PM, Emmanuel Lecharnyelecha...@gmail.comwrote:
...
As soon as you consider that a delete operation will need to update all the
index the deleted entry uses, you see that you can benefit from having such
Emmanuel Lecharny wrote:
Hi guys,
snip
So here is what I suggest :
- get rid of those reverse index
- or, at least, make it optionnal
thoughts ?
You described pure attribute value indices (including system indices
like objectClass and entryUUID as well as user indices like cn or uid).
Emmanuel Lécharny schrieb:
On 5/13/10 8:08 AM, Alex Karasulu wrote:
Hi Emmanuel,
On Sun, May 9, 2010 at 6:42 PM, Emmanuel
Lecharnyelecha...@gmail.comwrote:
...
As soon as you consider that a delete operation will need to update
all the
index the deleted entry uses, you see that you
On 5/13/10 11:10 AM, Stefan Seelmann wrote:
Emmanuel Lécharny schrieb:
Well, not anymore :)
They are still used. In fact there are more reverse methods in Index
class:
Damnit ! When I copy/past those method's name from the mail, and search
them, I found nothing.
It seems that
Hi guys,
in an attempt to jump into the backend database, and due to the problem
we have on the add operation, I looked at the current implementation
(based on JDBM) and the way we use it.
Right now, we have one master table containing all the entries, plus
many indexes, some of them being
On 9 mai 2010, at 17:42, Emmanuel Lecharny wrote:
Hi guys,
in an attempt to jump into the backend database, and due to the problem we
have on the add operation, I looked at the current implementation (based on
JDBM) and the way we use it.
Right now, we have one master table containing
