<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace">Hi list,</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">As you may have noticed, there&#39;s a bit of an ambiguity on how query objects are created - some have a constructor from a parameters object, some have a constructor from a parameters object and an EngineContext, and some have both.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">This ambiguity leads to all sorts of annoying bugs where some queries can&#39;t be used as internal queries (because they lack the proper constructor), or other queries couldn&#39;t be used without a context.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">I just merged a series of patches to streamline queries creation and eliminate the problem.</div><div class="gmail_default" style="font-family:monospace,monospace">Looking forwards, queries should have a single constructor receiving a parameters object and a context and pass them on to super. A unit test was added to enforce this constructor&#39;s existence in build time. From a caller&#39;s perspective, nothing&#39;s changed, and all of the Backend#run[Internal]Query methods were left unchanged.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">The build, CI and OST suite were ran on this patch series and everything seems to be in order, but please let me know if you encounter any issues.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">-Allon</div></div>