I think I fixed it. It'll be available from our maven repo soon!

2009/12/21 Mattias Persson <matt...@neotechnology.com>:
> Ok great, I'll look into this error and see if I can locate that bug.
>
> 2009/12/21 Sebastian Stober <sto...@ovgu.de>:
>> Hello Mattias,
>>
>> thank you for your quick reply. The new behavior you describe looks like
>> what I would expect. (I think fulltext queries should generally be
>> treated case-insensitive)
>>
>> The original junit-test now completes without error. However, there
>> still seems to be something odd.
>>
>> If I modify the setup code (before I run any test queries) like this,
>> the LuceneFulltextIndexService is messed up:
>>
>> // using LuceneFulltextIndexService
>>
>> andy.setProperty( "name", "Andy Wachowski" );
>> andy.setProperty( "title", "Director" );
>> //      larry.setProperty( "name", "Larry Wachowski" ); //old
>> larry.setProperty( "name", "Andy Wachowski" ); //new(deliberately wrong)
>> larry.setProperty( "title", "Director" );
>> index.index( andy, "name", andy.getProperty( "name" ) );
>> index.index( andy, "title", andy.getProperty( "title" ) );
>> index.index( larry, "name", larry.getProperty( "name" ) );
>> index.index( larry, "title", larry.getProperty( "title" ) );
>>
>> // new: fixing the name of larry
>> index.removeIndex( larry, "name", larry.getProperty( "name" ) );
>> larry.setProperty( "name", "Larry Wachowski" );
>> index.index( larry, "name", larry.getProperty( "name" ) );
>>
>> // start the test...
>> index.getNodes( "name", "wachowski" )
>> now returns only larry instead of both nodes.
>>
>> Any ideas? It looks like the index entry for andy is removed as well.
>>
>> Cheers,
>> Sebastian
>>
>>> Message: 4
>>> Date: Fri, 18 Dec 2009 10:16:33 +0100
>>> From: Mattias Persson <matt...@neotechnology.com>
>>> Subject: Re: [Neo] Strange behavior of LuceneFulltextIndexService
>>> To: Neo user discussions <user@lists.neo4j.org>
>>> Message-ID:
>>>       <acdd47330912180116l7d5fe082g2322f45712906...@mail.gmail.com>
>>> Content-Type: text/plain; charset=UTF-8
>>>
>>> I've made some changes to make LuceneFulltextIndexService and
>>> LuceneFulltextQueryIndexService behave more natural. So this is the
>>> new (and better) deal (copied from the javadoc, from your example!):
>>>
>>> LuceneFulltextIndexService:
>>>     /**
>>>      * Since this is a "fulltext" index it changes the contract of this 
>>> method
>>>      * slightly. It treats the {...@code value} more like a query in than 
>>> you can
>>>      * query for individual words in your indexed values.
>>>      *
>>>      * So if you've indexed node (1) with value "Andy Wachowski" and node 
>>> (2)
>>>      * with "Larry Wachowski" you can expect this behaviour if you query 
>>> for:
>>>      *
>>>      * o "andy"            --> (1)
>>>      * o "Andy"            --> (1)
>>>      * o "wachowski"       --> (1), (2)
>>>      * o "andy larry"      -->
>>>      * o "larry Wachowski" --> (2)
>>>      * o "wachowski Andy"  --> (1)
>>>      */
>>>
>>> LuceneFulltextQueryIndexService:
>>>     /**
>>>      * Here the {...@code value} is treated as a lucene query,
>>>      * http://lucene.apache.org/java/2_9_1/queryparsersyntax.html
>>>      *
>>>      * So if you've indexed node (1) with value "Andy Wachowski" and node 
>>> (2)
>>>      * with "Larry Wachowski" you can expect this behaviour if you query 
>>> for:
>>>      *
>>>      * o "andy"            --> (1)
>>>      * o "Andy"            --> (1)
>>>      * o "wachowski"       --> (1), (2)
>>>      * o "andy AND larry"  -->
>>>      * o "andy OR larry"   --> (1), (2)
>>>      * o "larry Wachowski" --> (1), (2) // lucene's default operator is OR
>>>      *
>>>      * The default AND/OR behaviour can be changed by overriding
>>>      * {...@link #getDefaultQueryOperator(String, Object)}.
>>>      */
>>>
>>>
>>> Does this make more sense?
>>>
>>> 2009/12/17 Mattias Persson <matt...@neotechnology.com>:
>>>> That is indeed a behaviour which needs to be straightened out, I see
>>>> that it doesn't behave as expected all the time. I'll look into this
>>>> as soon as possible.
>>>>
>>>> Btw. is it a good idea to have LuceneFulltextIndexService and
>>>> LuceneFulltextQueryIndexService be case-insensitive, should it be
>>>> configurable or would it be nice with case-sensitivity instead (so
>>>> that you'd have to run .toLowerCase(), or something, on your strings
>>>> and queries to get such behaviour)?
>>>>
>>>> 2009/12/17 Sebastian Stober <sto...@ovgu.de>:
>>>>> Hello,
>>>>>
>>>>> I ran into some strange behavior of the LuceneFulltextIndexService in
>>>>> the application I am building. So I put together a junit test based on
>>>>> the example from
>>>>> http://wiki.neo4j.org/content/Indexing_with_IndexService#Wachowski_brothers_example
>>>>>
>>>>> Here's what I found out using 0.9-SNAPSHOT of index-util (version 0.8
>>>>> wasn't any better):
>>>>>
>>>>> >> snip
>>
>>
>>
>> _______________________________________________
>> Neo mailing list
>> User@lists.neo4j.org
>> https://lists.neo4j.org/mailman/listinfo/user
>>
>
>
>
> --
> Mattias Persson, [matt...@neotechnology.com]
> Neo Technology, www.neotechnology.com
>



-- 
Mattias Persson, [matt...@neotechnology.com]
Neo Technology, www.neotechnology.com
_______________________________________________
Neo mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user

Reply via email to