I recently implemented the ability for multiple users to open the
index in the same process ("whoa", you might think, but this has been
a single user application forever and we're only just making the
platform capable of supporting more than that.)
I found that filters are being stored twice and s
On Thu, Nov 22, 2012 at 11:10 PM, Trejkaz wrote:
>
> As for actually doing the invalidation, CachingWrapperFilter itself
> doesn't appear to have any mechanism for invalidation at all, so I
> imagine I will be building a variation of it with additional methods
> to invalidate parts of the cache.
On Tue, Nov 27, 2012 at 9:31 AM, Robert Muir wrote:
> On Thu, Nov 22, 2012 at 11:10 PM, Trejkaz wrote:
>
>>
>> As for actually doing the invalidation, CachingWrapperFilter itself
>> doesn't appear to have any mechanism for invalidation at all, so I
>> imagine I will be building a variation of it
On Tue, Nov 27, 2012 at 6:17 AM, Trejkaz wrote:
>
> Ah, yeah... I should have been clearer on what I meant there.
>
> If you want to make a filter which relies on data that isn't in the
> index, there is no mechanism for invalidation. One example of it is if
> you have a filter which essentially
On Wed, Nov 28, 2012 at 2:09 AM, Robert Muir wrote:
>
> I don't understand how a filter could become invalid even though the reader
> has not changed.
I did state two ways in my last email, but just to re-iterate:
(1): The filter reflects a query constructed from lines in a text
file. If some ot
On Wed, Nov 28, 2012 at 12:27 AM, Trejkaz wrote:
> On Wed, Nov 28, 2012 at 2:09 AM, Robert Muir wrote:
> >
> > I don't understand how a filter could become invalid even though the
> reader
> > has not changed.
>
> I did state two ways in my last email, but just to re-iterate:
>
> (1): The filter
On Wed, Nov 28, 2012 at 6:28 PM, Robert Muir wrote:
> My point is really that lucene (especially clear in 4.0) assumes
> indexreaders are immutable points in time. I don't think it makes sense for
> us to provide any e.g. filtercaching or similar otherwise, because this is
> a key simplification t
On Thu, Nov 29, 2012 at 4:57 PM, Trejkaz wrote:
> doubt we're not
Rats. Accidentally double-negatived that. I doubt we are the only ones. *
TX
-
To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
For additional com
We have something similar with documens that can be tagged (and have
many other relations). But for the matter of search we have two
distinctions from your aproach:
- We do actually index the relation's id (i.e. the tag's id) as part of
the lucene-document and update the document if that relatio
