I saw this old thread and could just fill in with more information.

So, the IndexService.getNodes() now returns an IndexHits result, which
is an Iterable with a size() method on it. The size is given back from
lucene so there's no overhead in calling size() at all.

The LuceneIndexService will create a new document for each call to
LuceneIndexService.index() method. This is because it'd be quite slow
to try to merge with potential existing matches a.s.o.

2009/9/18 Andreas Kollegger <akolleg...@tembopublic.org>:
> For my use cases at least, total node counts are needed so often that
> I'd love the optimized version. What's the relationship between
> number of documents and nodes? Would that be all indexed nodes
> regardless of the key?
>
> On Sep 18, 2009, at 3:46 AM, Mattias Persson wrote:
>
>> Looking at the Lucene javadocs I can see that you can ask an index
>> (IndexReader) the number of documents there are in it and it'd be
>> simple to expose a size() method in the IndexService interface or
>> perhaps on the LuceneIndexService class...
>>
>> Would that be something worth/good to implement?
>>
>> 2009/9/18 Andreas Guenther <andreas.guent...@web.de>:
>>> actually, disregard my suggestion as I didn't read the word index
>>> in your question before.
>>>
>>> -AndreasAndreas Guenther wrote:
>>>
>>> The service API has a getAllNodes() call. Iterate and count through
>>> it.
>>>
>>>
>>>
>>> -AndreasAndreas Kollegger wrote:
>>>
>>>
>>>
>>> Hi all,
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> For nodes that are kept in the indexed service, is there a more
>>> clever
>>>
>>>
>>>
>>> (and hopefully efficient) way to get the node count than manually
>>>
>>>
>>>
>>> iterating over all the nodes in the index and actually counting. I
>>>
>>>
>>>
>>> don't see anything obvious in the IndexService() interface, and am
>>> not
>>>
>>>
>>>
>>> sure if I've overlooked something useful somewhere else.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> I suppose I could always keep a running tally somewhere, but then I'd
>>>
>>>
>>>
>>> have to be careful to keep it in sync with reality. Ideally the count
>>>
>>>
>>>
>>> would be closer to the metal.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Thanks,
>>>
>>>
>>>
>>> Andreas
>>>
>>>
>>>
>>> _______________________________________________
>>>
>>>
>>>
>>> Neo mailing list
>>>
>>>
>>>
>>> User@lists.neo4j.org
>>>
>>>
>>>
>>> https://lists.neo4j.org/mailman/listinfo/user
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>>
>>> Neo mailing list
>>>
>>> User@lists.neo4j.org
>>>
>>> https://lists.neo4j.org/mailman/listinfo/user
>>>
>>>
>>> _______________________________________________
>>> Neo mailing list
>>> User@lists.neo4j.org
>>> https://lists.neo4j.org/mailman/listinfo/user
>>>
>>
>>
>>
>> --
>> Mattias Persson, [matt...@neotechnology.com]
>> Neo Technology, www.neotechnology.com
>> _______________________________________________
>> Neo mailing list
>> User@lists.neo4j.org
>> https://lists.neo4j.org/mailman/listinfo/user
>
> _______________________________________________
> Neo mailing list
> User@lists.neo4j.org
> https://lists.neo4j.org/mailman/listinfo/user
>



-- 
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