aurora-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Maxim Khutornenko" <ma...@apache.org>
Subject Re: Review Request 24243: DB schema for the job update store.
Date Mon, 04 Aug 2014 20:28:09 GMT


> 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
> 
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message