directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Selcuk AYA <ayasel...@gmail.com>
Subject Re: Modification of Index Entries through search engine
Date Wed, 30 Nov 2011 06:00:53 GMT
On Wed, Nov 30, 2011 at 1:56 AM, Emmanuel Lecharny <elecharny@gmail.com> wrote:
> 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.

So I still dont get why modifying the index entry through setValue at
evaluators is necessary( the hacky way it is done is another point).
We have the id of the entry at this point and it is read from the
master table to get the attribute value to evaluate. When you dont
have an index, you have to have the entry fed to the evaluator either
through master table or from some other node in the search tree anyway
and then we have all the attribute values we need. So it seems to me
redundant to set this value on the index value. I will comment out
this code and try the tests. Please let me know if you are aware of a
case where setting value on the index entry at evaluators is useful.
>
>>
>> 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