> On March 30, 2016, 5:59 p.m., Bill Farner wrote:
> > src/main/java/org/apache/aurora/scheduler/storage/log/SnapshotStoreImpl.java,
> >  line 180
> > <https://reviews.apache.org/r/45467/diff/1/?file=1318681#file1318681line180>
> >
> >     As i read this, i found myself wishing for something that appears to be 
> > [`FileMigrationLoader`](https://github.com/mybatis/migrations/blob/master/src/main/java/org/apache/ibatis/migration/FileMigrationLoader.java)
> >  but with the ability to load resources from the classpath.
> >     
> >     Have you given any thought to using that instead?

Are you saying you'd prefer migrations be stored as sql scripts rather than 
classes? It think it would be possible to write something on top of 
`FileMigrationLoader` that did that, but I actually kind of prefer the 
class-based representation since we want to define both up and down scripts. I 
don't love the way the file-based scripts represent both in the same file with 
an `@UNDO` annotation; this seems like it could potentially be brittle.


- Joshua


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


On March 30, 2016, 3:41 a.m., Joshua Cohen wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/45467/
> -----------------------------------------------------------
> 
> (Updated March 30, 2016, 3:41 a.m.)
> 
> 
> Review request for Aurora, Maxim Khutornenko and Bill Farner.
> 
> 
> Repository: aurora
> 
> 
> Description
> -------
> 
> THIS CODE IS NOT INTENDED TO BE COMMITTED.
> 
> This is just a spike to show a proof of concept for how we can effect 
> automatic migrations and rollbacks of the H2 schema. The code is very sloppy, 
> please use this to further the discussion on the mailing list about 
> migrations. If we agree this methodology is acceptable, I'll clean this up 
> and send out an actual review.
> 
> That said...
> 
> The general gist here is:
> 
> 1. Use MyBatis Migrations which has built in support for specifying an up and 
> a down script for db changes and also makes it easy to locate all existing 
> migrations on the classpath.
> 2. When applying a migration, write the downgrade script to the changelog 
> table in the database.
> 3. Before actually applying migrations, check all changes in the changelog 
> table. If the corresponding migration does not exist on the classpath, we 
> assume this is a rollback and run the downgrade script from the changelog 
> table and delete the corresponding changelog row.
> 
> 
> Diffs
> -----
> 
>   build.gradle ad5ec5c4afe4dd5c2189d0680692a7409f0417a9 
>   examples/vagrant/upstart/aurora-scheduler.conf 
> 120b89a1dc10a259940cb9527eb2517f19d04471 
>   
> src/main/java/org/apache/aurora/scheduler/http/api/security/HttpSecurityModule.java
>  e32862034a1ad47dae8fff89cb04deb34ccd90e2 
>   src/main/java/org/apache/aurora/scheduler/storage/db/DbModule.java 
> baf460e987d0a6ba2810507695fe118b6b502f87 
>   
> src/main/java/org/apache/aurora/scheduler/storage/db/migration/V001_CreateUnifiedContainerTables.java
>  PRE-CREATION 
>   
> src/main/java/org/apache/aurora/scheduler/storage/log/SnapshotStoreImpl.java 
> 6fee2510d044515e0704cf20ec0ba77231050ec4 
> 
> Diff: https://reviews.apache.org/r/45467/diff/
> 
> 
> Testing
> -------
> 
> I manually verified in vagrant that this works as expected for upgrades with 
> migrations, upgrades without migrations and rollbacks.
> 
> 
> Thanks,
> 
> Joshua Cohen
> 
>

Reply via email to