Hi,
currently, all the index we create have two underlying tables : forward
and reverse. As we have seen, it's sometime spurious to have a reverse
index (like for the presence index, the entryUUID or ObjectClass)
W can modify slightly the implementation to have index instance having
only a forward table, by adding a boolean flag in the constructor :
/**
* Creates a JdbmIndex instance for a give AttributeId
*/
public JdbmIndex( String attributeId, boolean withReverse )
{
super( attributeId, withReverse );
initialized = false;
}
and in the init() metjod, if the flag is true, we create the reverse
index, otherwise we don't.
This does not modify a lot the interface, plus it's easy to modify the
methods that use the reverse table :
/**
* {@inheritDoc}
*/
public void drop( Long entryId ) throws Exception
{
// Build a cursor to iterate on all the keys referencing
// this entryId
Cursor<Tuple<Long, K>> values = reverse.cursor( entryId );
while ( values.next() )
{
// Remove the Key -> entryId from the index
forward.remove( values.get().getValue(), entryId );
}
// Remove the id -> key from the reverse index
if ( withReverse )
{
reverse.remove( entryId );
}
}
Here, before removing the entryId from the reverse table, we check that
the withReverse flag is true.
Really, it's quite simple. I have experimented this modification, with
the presence, objectClass and entryCSN index configured to have no
reverse index, and all the tests are passing green :
protected void setupSystemIndices() throws Exception
{
// add missing system indices
if ( getPresenceIndex() == null )
{
Index<String, Entry, ID> index = createSystemIndex(
ApacheSchemaConstants.APACHE_PRESENCE_AT_OID, partitionPath, NO_REVERSE );
addIndex( index );
}
...
Should I commit the change in trunk, or should I do that in a branch ?
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
