: I think to do this efficiently you'd need to modify Lucene's builtin query
: classes (eg TermQuery) such that during the scoring process, in addition to
: simply computing its contribution to the document's score, it would also
: record further information like total number of occurrences of eac
Can you share what the actual problem is that you are trying to
solve? It might help put things in context for me. I'm guessing you
are doing some type of co-occurrence analysis, but...
More below.
On Nov 13, 2008, at 11:08 AM, Sven wrote:
First - I apologize for the double post on my ear
Thanks Mark ,
this gets me moving. I will look into it somewhere soon.
Geert-Jan
markrmiller wrote:
>
> Like I said, its pretty easy to add this, but its also going to suck.
> Kind of exposes the fact that its missing the right extensibility at the
> moment. Things are still a bit ugly ov
Like I said, its pretty easy to add this, but its also going to suck.
Kind of exposes the fact that its missing the right extensibility at the
moment. Things are still a bit ugly overall.
Your going to need new CacheKeys for the data types you want to support.
A CacheKey builds and provides a
That ArrayObject suggestion makes sense to me. It amost seemed to be as if
you were referring as this option (or at least the interfaces needed to
implement this) were already available as 1 out of 2 options available in
831?
Could you give me a hint at were I have to be looking to extend what y
But isn't this pluggability / visibility issues resolved with using
lucene-831? Or did you roll-your-own before 831 was available?
PabloS wrote:
>
> I have the same problem with cache and too many sorted fields, and had to
> implement a big workaround to be able to plug my own cache implementa
