<div dir="auto"><div><br><div class="gmail_extra"><br><div class="gmail_quote">On 27 Jun 2017 10:13, &quot;Radim Vansa&quot; &lt;<a href="mailto:rvansa@redhat.com">rvansa@redhat.com</a>&gt; wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
I am working on entry version history (again). In Como we&#39;ve discussed<br>
that previous values are needed for (continuous) query and reliable<br>
listeners, </blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">Index based queries also require the previous value on a write - unless we can get &quot;strongly typed caches&quot; giving guarantees about the class to represent the content of a cache to be unique. </div><div dir="auto"><br></div><div dir="auto">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. </div><div dir="auto"><br></div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">so I wonder what should we do with functional write-only<br>
commands. These are different to commands with flags, because flags<br>
(other than ignore return value) are expected to break something.</blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">Sorry I hope to not derail the thread but let&#39;s remind that we hope to evolve beyond &quot;flags are expected to break stuff&quot; ; we never got to it but search the mailing list. </div><div dir="auto"><br></div><div dir="auto">Since flags are exposed to the user I would rather they&#39;re not allowed to break things. </div><div dir="auto">Could they be treated as hints? Ignore the flag (and warn?) if the used  configuration/integrations veto them.</div><div dir="auto"><br></div><div dir="auto">Alternatively, let&#39;s remove them from API. Remember &quot;The Jokre&quot; 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. </div><div dir="auto"><br></div><div dir="auto">So assuming they become either &quot;safe&quot; or internal, maybe you can take advantage of them? </div><div dir="auto"><br></div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I see<br>
the available options as:<br>
<br>
1) run write-only commands &#39;optimized&#39;, ignoring any querying and such<br>
(warn user that he will break it)<br>
<br>
2) run write-only without any optimization, rendering them useless<br>
<br>
3) detect when querying is set up (ignoring listeners and maybe other<br>
stuff that could get broken)<br></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">Might be useful for making a POC work, but I believe query will be very likely to be often enabled. </div><div dir="auto">Having an either / or switch for different features in Infinispan will make it harder to use and understand, so I&#39;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.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
4) remove write-only commands completely (and probably functional<br>
listeners as well because these will lose their purpose)<br></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">+1 to remove &quot;unconditional writes&quot;, at least an entry version check should be applied. </div><div dir="auto">I believe we had already pointed out this would eventually happen, pretty much for the reasons you&#39;re hitting now. </div><div dir="auto"><br></div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Right now I am inclined towards 4). There could be some internal use<br>
(e.g. multimaps) that could use 1) which is ran without a fancy setup,<br>
though, but it&#39;s asking for trouble.<br></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">I agree! </div><div dir="auto"><br></div><div dir="auto">Thanks </div><div dir="auto"><br></div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
WDYT?<br>
<font color="#888888"><br>
Radim<br>
<br>
--<br>
<br>
Radim Vansa &lt;<a href="mailto:rvansa@redhat.com">rvansa@redhat.com</a>&gt;<br>
JBoss Performance Team<br>
<br>
______________________________<wbr>_________________<br>
infinispan-dev mailing list<br>
<a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/infinispan-<wbr>dev</a><br>
</font></blockquote></div><br></div></div></div>