> On Feb. 3, 2015, 12:48 a.m., Maxim Khutornenko wrote:
> > The ticket suggests a possibility of the optimization route. Would you mind 
> > commenting why you decided to remove it after all?

Sure.  Kevin rightly pointed out that it's odd for us to check this _one_ 
invariant when there are many others.  Put another way, we can't check 
everything, and doing this one check suggests that we are uncertain of our 
ability to maintain integrity of the data in this one specific way.

Once we move this table to SQL, we will be in a much better position to 
continually enforce this type of constraint.


- Bill


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


On Feb. 3, 2015, 12:42 a.m., Bill Farner wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/30535/
> -----------------------------------------------------------
> 
> (Updated Feb. 3, 2015, 12:42 a.m.)
> 
> 
> Review request for Aurora, David McLaughlin, Kevin Sweeney, and Maxim 
> Khutornenko.
> 
> 
> Bugs: AURORA-1090
>     https://issues.apache.org/jira/browse/AURORA-1090
> 
> 
> Repository: aurora
> 
> 
> Description
> -------
> 
> Remove shard uniqueness check from scheduler recovery phase.
> 
> 
> Diffs
> -----
> 
>   src/main/java/org/apache/aurora/scheduler/storage/StorageBackfill.java 
> 1814658c044273f7c3a2348a16aea62e397cf860 
>   src/test/java/org/apache/aurora/scheduler/storage/StorageBackfillTest.java 
> 93773eb5ba3bee1b3296e69ea30eabb531eeb661 
> 
> Diff: https://reviews.apache.org/r/30535/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Bill Farner
> 
>

Reply via email to