Re: [infinispan-dev] Write-only commands

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(a)redhat.com&gt; 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(a)redhat.com&gt; 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(a)redhat.com&gt; >> JBoss Performance Team >> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> >> >> >> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> >> _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev