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 <anis...@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" <rva...@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 <rva...@redhat.com> >>> JBoss Performance Team >>> >>> _______________________________________________ >>> infinispan-dev mailing list >>> infinispan-dev@lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >>> >>> >>> >>> >>> _______________________________________________ >>> infinispan-dev mailing list >>> infinispan-dev@lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >>> >>> > _______________________________________________ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Radim Vansa <rva...@redhat.com> JBoss Performance Team _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
