directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <elecha...@gmail.com>
Subject Re: Modification of Index Entries through search engine
Date Tue, 29 Nov 2011 23:56:53 GMT
On 11/29/11 8:53 PM, Selcuk AYA wrote:
> Hi,
> I am doing some tests on txns and the following causes problems for the test:
>      most of the default search engine evaluators cast Index<UUID>  to
> Index<Object>  or Index<String>  and then call the setValue method of
> the index entry to modify it  when there is no index on the attribute.
Ok.

Index on attributes can be set on String value or Binary values. But as 
we also use some index for entries (ie, Long, before you switched to 
UUID), we had no way to simply decide what was the exact type of the index.

This is bad. There is an old JIRA opened describing a similar issue : 
https://issues.apache.org/jira/browse/DIRSERVER-1458

It has to be fixed.
> Index<UUID>  entry comes from the uuid cursor.  I would like to get rid
> of this as it is causing problems for the txns layer. Txn layer is
> maintaining some set of index entries in memory and when they are
> modified by the search engine it gets confused. In general any layer
> or cursor which maintained a cache of index entries would get confused
> in such a scenario.
>
> Please let me the reason we change the index entry in such a way and
> we can hopefully get rid of it. I commented out such code for the
> cases it caused me trouble and the tests passed.
I just think we change them to be able to handle all the different 
cases. Not in the best possible way, I agree.
>
> An example is here. ( Note the inconsistency-- setValue is not called
> for the binary value case):

This is a very specific piece of code. There is no inconsistency, just a 
missing comment (see 
http://svn.apache.org/viewvc?view=revision&revision=950633).

In two words, this code was just an anticipation for when we will 
support SUBSTRINg on binary values (we don't support that atm).
>
>   // if the attribute exists and the pattern matches return true
>          if ( attr != null )
>          {
>              /*
>               * Cycle through the attribute values testing normalized version
>               * obtained from using the substring matching rule's normalizer.
>               * The test uses the comparator obtained from the appropriate
>               * substring matching rule.
>               */
>              if ( attr.isHumanReadable() )
>              {
>                  for ( Value<?>  value : attr )
>                  {
>                      String strValue = ( String ) value.getNormValue();
>
>                      // Once match is found cleanup and return true
>                      if ( regex.matcher( strValue ).matches() )
>                      {
>                          // before returning we set the normalized value
>                          indexEntry.setValue( strValue );
>                          return true;
>                      }
>                  }
>              }
>              else
>              {
>                  // Slightly more complex. We won't be able to use a
> regex to check
>                  // the value.
>                  for ( Value<?>  value : attr )
>                  {
>                      byte[] byteValue = (byte[])value.getNormValue();
>
>                      // Once match is found cleanup and return true
>                      // @TODO : implement this check.
>                      /*
>                      if ( check( byteValue ) )
>                      {
>                          // before returning we set the normalized value
>                          indexEntry.setValue( byteValue );
>                          return true;
>                      }
>                      */
>                  }
>              }

In any case, we *must* clarify all those casts and bad generic usage. 
This is way too messy...


-- 
Regards,
Cordialement,
Emmanuel L├ęcharny
www.iktek.com


Mime
View raw message