> On Aug. 4, 2014, 7:27 p.m., Bill Farner wrote:
> >

Current design assumes H2 ARRAY type is supported in MyBatis.


> On Aug. 4, 2014, 7:27 p.m., Bill Farner wrote:
> > src/main/resources/org/apache/aurora/scheduler/storage/db/schema.sql, line 
> > 100
> > <https://reviews.apache.org/r/24243/diff/1/?file=650526#file650526line100>
> >
> >     REFERENCES update_statuses(id)

Done.


> On Aug. 4, 2014, 7:27 p.m., Bill Farner wrote:
> > src/main/resources/org/apache/aurora/scheduler/storage/db/schema.sql, line 
> > 80
> > <https://reviews.apache.org/r/24243/diff/1/?file=650526#file650526line80>
> >
> >     Please prefix tables with job_ where appropriate.

Done.


> On Aug. 4, 2014, 7:27 p.m., Bill Farner wrote:
> > src/main/resources/org/apache/aurora/scheduler/storage/db/schema.sql, line 
> > 107
> > <https://reviews.apache.org/r/24243/diff/1/?file=650526#file650526line107>
> >
> >     What's the motivation behind separating updates, update_configs, and 
> > update_settings?  They seem tightly-coupled enough that they might benefit 
> > from being combined.

The update_settings can be merged with updates (Done). 

The update_configs have to be separate as updates will have multiple TaskConfig 
records covering different instance ranges in "old" config domain. The "new" 
task config will also be stored in this table.


> On Aug. 4, 2014, 7:27 p.m., Bill Farner wrote:
> > src/main/resources/org/apache/aurora/scheduler/storage/db/schema.sql, line 
> > 112
> > <https://reviews.apache.org/r/24243/diff/1/?file=650526#file650526line112>
> >
> >     What's this for?

To separate new from old task configs.


> On Aug. 4, 2014, 7:27 p.m., Bill Farner wrote:
> > src/main/resources/org/apache/aurora/scheduler/storage/db/schema.sql, line 
> > 123
> > <https://reviews.apache.org/r/24243/diff/1/?file=650526#file650526line123>
> >
> >     I'm an anti-fan of flags that say "do not do X", as they can lead to 
> > confusing double-negatives.  Consider s/do_not_//

This maps into the do_not_rollback_on_failure flag in thrift UpdateSettings. 
The idea here is that a default False value (when not initialized) would not 
break the default current behavior to rollback. Do you suggest we change it in 
thrift too?


- Maxim


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


On Aug. 4, 2014, 6:02 p.m., Maxim Khutornenko wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/24243/
> -----------------------------------------------------------
> 
> (Updated Aug. 4, 2014, 6:02 p.m.)
> 
> 
> Review request for Aurora, David McLaughlin, Kevin Sweeney, and Bill Farner.
> 
> 
> Bugs: AURORA-612
>     https://issues.apache.org/jira/browse/AURORA-612
> 
> 
> Repository: aurora
> 
> 
> Description
> -------
> 
> DB tables for the job update store. Sending out early to solicit feedback 
> before moving to mappers.
> 
> 
> Diffs
> -----
> 
>   src/main/resources/org/apache/aurora/scheduler/storage/db/schema.sql 
> 5358b45102f53eea97a1ca709ba9375daa91a3ef 
> 
> Diff: https://reviews.apache.org/r/24243/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Maxim Khutornenko
> 
>

Reply via email to