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