[infinispan-dev] Write-only commands

[Radim Vansa]

I am with Adrian here, we want the core as simple as possible. The more 
ifs, the more bugs - it's hard to track all the edge cases. And besides 
declarative approach (saying that this cache can contain only entities 
X, Y and Z) and only checking that, I think that there's little space 
for 'loading just the metadata', because there are (currently) only two 
sources if the entry is not present: remote nodes and cache store. The 
actual read operation is cheapish, the cost is in going to the other 
node/DB machine. The same for maintenance perspective: you need to check 
for errors & have the correct, the type of value (just metadata/whole 
prev value) does not change it.

R.

On 06/27/2017 11:53 PM, Adrian Nistor wrote:
> The needs for continuous query are stronger than and include the needs
> of normal query.
> So by fixing what is needed for continuous query we can all live a happy
> life without needing to provide "*yet another* form of previous-version
> loading". The reverse is not true.
> You'll have to convince me this extra mechanism's added complexity is
> worth the effort :)
>
>
> On 06/28/2017 12:00 AM, Sanne Grinovero wrote:
>> On 27 June 2017 at 13:43, Adrian Nistor <anistor at redhat.com> wrote:
>>> I've said this in a previous thread on this same issue, I will repeat myself
>>> as many times as needed.
>>>
>>> Continuous queries require the previous value itself, not just knowledge of
>>> the type of the previous value. Strongly typed caches solve no problem here.
>> Why do you need to repeat this, Radim already captured this
>> requirement for CQ in the premise of this very thread?
>>
>>> So if we half-fix query but leave CQ broken I will be half-happy (ie. very
>>> depressed) :)
>> There must be a misunderstanding. I merely highlighted the needs for
>> indexed queries, and point out that it might be useful to have *yet
>> another* form of previous-version loading as this specific
>> circumstance would just need some metadata. I'd never suggest to
>> replace or remove the capability to load the "full" previous version,
>> definitely not meaning to suggest to break CQ and many other essential
>> use cases.
>>
>>> I'd remove these commands completely or possibly remove them just from
>>> public API and keep them internal.
>>>
>>> Adrian
>>>
>>>
>>>
>>> On 06/27/2017 01:28 PM, Sanne Grinovero wrote:
>>>
>>>
>>>
>>> On 27 Jun 2017 10:13, "Radim Vansa" <rvansa at redhat.com> wrote:
>>>
>>> Hi,
>>>
>>> I am working on entry version history (again). In Como we've discussed
>>> that previous values are needed for (continuous) query and reliable
>>> listeners,
>>>
>>>
>>> Index based queries also require the previous value on a write - unless we
>>> can get "strongly typed caches" giving guarantees about the class to
>>> represent the content of a cache to be unique.
>>>
>>> Essentially we only need to know the type of the previous object. It might
>>> be worth having a way to load the type metadata if the previous value only.
>>>
>>> so I wonder what should we do with functional write-only
>>> commands. These are different to commands with flags, because flags
>>> (other than ignore return value) are expected to break something.
>>>
>>>
>>> Sorry I hope to not derail the thread but let's remind that we hope to
>>> evolve beyond "flags are expected to break stuff" ; we never got to it but
>>> search the mailing list.
>>>
>>> Since flags are exposed to the user I would rather they're not allowed to
>>> break things.
>>> Could they be treated as hints? Ignore the flag (and warn?) if the used
>>> configuration/integrations veto them.
>>>
>>> Alternatively, let's remove them from API. Remember "The Jokre" POC was
>>> intentionally designed to explore pushing the limits on performance w/o end
>>> users having to solve puzzles, such as learning details about these flags
>>> and their possible side effects.
>>>
>>> So assuming they become either "safe" or internal, maybe you can take
>>> advantage of them?
>>>
>>> I see
>>> the available options as:
>>>
>>> 1) run write-only commands 'optimized', ignoring any querying and such
>>> (warn user that he will break it)
>>>
>>> 2) run write-only without any optimization, rendering them useless
>>>
>>> 3) detect when querying is set up (ignoring listeners and maybe other
>>> stuff that could get broken)
>>>
>>>
>>> Might be useful for making a POC work, but I believe query will be very
>>> likely to be often enabled.
>>> Having an either / or switch for different features in Infinispan will make
>>> it harder to use and understand, so I'd rather see work on the right design
>>> as taking temporary shortcuts risks baking into stone features which we
>>> later struggle to fix or maintain.
>>>
>>>
>>> 4) remove write-only commands completely (and probably functional
>>> listeners as well because these will lose their purpose)
>>>
>>>
>>> +1 to remove "unconditional writes", at least an entry version check should
>>> be applied.
>>> I believe we had already pointed out this would eventually happen, pretty
>>> much for the reasons you're hitting now.
>>>
>>>
>>> Right now I am inclined towards 4). There could be some internal use
>>> (e.g. multimaps) that could use 1) which is ran without a fancy setup,
>>> though, but it's asking for trouble.
>>>
>>>
>>> I agree!
>>>
>>> Thanks
>>>
>>>
>>> WDYT?
>>>
>>> Radim
>>>
>>> --
>>>
>>> Radim Vansa <rvansa at redhat.com>
>>> JBoss Performance Team
>>>
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>
>>>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


-- 
Radim Vansa <rvansa at redhat.com>
JBoss Performance Team