> On March 29, 2016, 4:20 p.m., John Sirois wrote:
> > How would these queries produce incorrect results as compared to previous 
> > queries?  Perviously, a check for the collection being null would have had 
> > to have been made by the caller (or a check for !IsSet) to skip the calls 
> > you've added precondition checks to.  The IsSet calls are now gone, meaning 
> > the call sites using those have been semantically adjusted.  I think this 
> > only leaves the callers who pass null of which there should be none due to 
> > the semantic change as well.
> 
> Bill Farner wrote:
>     If i understand you correctly - the problem is with call sites that 
> assume `Query.slaveScoped(ImmutableList.of()` translates into `SELECT xyz 
> WHERE slave_host IN ()` (always returning 0 rows).
>     
>     However, the semantic is now such that the above query is equivalent to 
> `SELECT xyz WHERE 1`.
> 
> Bill Farner wrote:
>     Oh, and to complete the thought - i am assuming that callers never mean 
> `WHERE 1` when they call `Query.slaveScoped(x)`.
> 
> John Sirois wrote:
>     I'm assuming the opposite. A generic query builder using this tool might 
> work through criteria, some of which are unset.  The unset criteria should 
> map to an always true ckause (WHERE 1), they should never map to an always 
> false clause (IN ()).  I say this from 10k feet above this code though, not 
> taking real call sites in-mind.  It may be there is no such code and so your 
> checks are fine in practice.
> 
> Bill Farner wrote:
>     | It may be there is no such code and so your checks are fine in practice.
>     
>     The reverse may also be true :-)
>     
>     I honestly don't have a strong opinion on this.  I'm okay if we just want 
> to recognize that the semantic has changed and we need to revisit call sites.
> 
> Bill Farner wrote:
>     For some anecdotal evidence - i surveyed the call sites (bad on me, it 
> was much less effort than i anticipated), and did not find any other 
> potentially-vulnerable callers.  So this patch may be much ado about nothing.
>     
>     Zameer - what do you think?

I also feel this patch may be much ado about nothing.


- Zameer


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/45457/#review125978
-----------------------------------------------------------


On March 29, 2016, 4:01 p.m., Bill Farner wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/45457/
> -----------------------------------------------------------
> 
> (Updated March 29, 2016, 4:01 p.m.)
> 
> 
> Review request for Aurora, John Sirois and Zameer Manji.
> 
> 
> Bugs: AURORA-1652
>     https://issues.apache.org/jira/browse/AURORA-1652
> 
> 
> Repository: aurora
> 
> 
> Description
> -------
> 
> Short of surveying call sites, i don't know the impact of this change.  
> However, my sense is that it's still better to fail fast than produce 
> incorrect results (due to the recent change in semantics of filtering by an 
> empty iterable).
> 
> 
> Diffs
> -----
> 
>   src/main/java/org/apache/aurora/scheduler/base/Query.java 
> c76b365f43eb6a3b9b0b63a879b43eb04dcd8fac 
> 
> Diff: https://reviews.apache.org/r/45457/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Bill Farner
> 
>

Reply via email to