[infinispan-dev] Write-only commands

[Adrian Nistor]

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