6:32 a.m.
Hi Adrian,
+1 good catch.
but what's a realistic use case for {indexing + eviction + no cachestore} ?
I guess some use cases might exist but I don't think it's critical,
would you agree?
and what about automatic eviction?
I think the guiding principle should be that if an entry can be
retrieved by key it should be searchable, and vice-versa, if I can
find it by running a query I should be able to load the result.
So expiry and other forms of eviction should also be considered, but
if there is no practical use case we can consider making this an
illegal configuration or simply log a warning about the particular
configuration.
Sanne
----- Original Message -----
Hi Sanne,
I found that manual eviction does not update the index. I think manual
eviction should behave like a remove, if there are no cache stores
configured.
Here's a test and a 'fix' :)
https://github.com/anistor/infinispan/tree/t_manual_evict_and_indexing
Let's discuss this when you have time.
There is also the more complex situation of in-DataContainer eviction ...
9:08 a.m.
New subject: manual eviction and indexing
I Agree. If indexing + (automatic) eviction + no cachestore is
currently allowed, then we should add a jira to add this config validation.
But what about manual eviction? Would it make sense to handle it the way
I did?
On 12/11/2013 02:32 PM, Sanne Grinovero wrote:
Hi Adrian,
+1 good catch.
but what's a realistic use case for {indexing + eviction + no cachestore} ?
I guess some use cases might exist but I don't think it's critical,
would you agree?
and what about automatic eviction?
I think the guiding principle should be that if an entry can be
retrieved by key it should be searchable, and vice-versa, if I can
find it by running a query I should be able to load the result.
So expiry and other forms of eviction should also be considered, but
if there is no practical use case we can consider making this an
illegal configuration or simply log a warning about the particular
configuration.
Sanne
----- Original Message -----
> Hi Sanne,
>
> I found that manual eviction does not update the index. I think manual
> eviction should behave like a remove, if there are no cache stores
> configured.
>
> Here's a test and a 'fix' :)
> https://github.com/anistor/infinispan/tree/t_manual_evict_and_indexing
>
> Let's discuss this when you have time.
>
> There is also the more complex situation of in-DataContainer eviction ...
>
9:40 a.m.
New subject: manual eviction and indexing
On 11 December 2013 15:08, Adrian Nistor <anistor(a)redhat.com> wrote:
I Agree. If indexing + (automatic) eviction + no cachestore is
currently
allowed, then we should add a jira to add this config validation.
But what about manual eviction? Would it make sense to handle it the way I
did?
Generally speaking I think you're on the right direction, but I'm not
sure how solid it is to rely on a "boolean usingStores" field.
Flag usage would make it more complex, but ok let's forget about
people trying to shoot themselves as that's hopeless.
Flags aside, we also have the case of CacheStore instances being added
on the fly (not sure if that was ever implemented, but for sure there
where good reasons and we opened JIRAs to make it possible), and we
have the quite common scenario in which a CacheStore is implemented as
"selective", i.e. it only stores a specific kind of types. For example
the JPACacheStore and the Lucene Directory Cachestore themselves.. the
latter only persists elements it recognizes as lucene index segments,
and it's useful for people who want to store the indexed data and the
index itself in the same cache.
Trying to check what kind of CacheStore you have is also a slippery
slope as you could have multiple chained ones.
Generally speaking I don't think it makes sense to use manual eviction
to get the effect of a remove, if you have your data indexed and there
is a cachestore. In such cases an eviction is not removing data, so it
should not cleanup any index. If the user wants to remove data, he
should use the remove method.
Should we add a configuration attribute to the indexing element, to
allow for "remove on eviction" ?
I hate adding more configuration elements, but I think making this
behavior explicitly defined is the least confusing option. Principle
of least astonishment.
Sanne
On 12/11/2013 02:32 PM, Sanne Grinovero wrote:
>
> Hi Adrian,
> +1 good catch.
>
> but what's a realistic use case for {indexing + eviction + no cachestore}
> ?
> I guess some use cases might exist but I don't think it's critical,
> would you agree?
>
> and what about automatic eviction?
>
> I think the guiding principle should be that if an entry can be
> retrieved by key it should be searchable, and vice-versa, if I can
> find it by running a query I should be able to load the result.
> So expiry and other forms of eviction should also be considered, but
> if there is no practical use case we can consider making this an
> illegal configuration or simply log a warning about the particular
> configuration.
>
> Sanne
>
> ----- Original Message -----
>>
>> Hi Sanne,
>>
>> I found that manual eviction does not update the index. I think manual
>> eviction should behave like a remove, if there are no cache stores
>> configured.
>>
>> Here's a test and a 'fix' :)
>> https://github.com/anistor/infinispan/tree/t_manual_evict_and_indexing
>>
>> Let's discuss this when you have time.
>>
>> There is also the more complex situation of in-DataContainer eviction ...
>>
4021
days inactive
4028
days old
infinispan-dev@lists.jboss.org
2 comments
2 participants
participants (2)
-
Adrian Nistor -
Sanne Grinovero