comeara / pillar

Pillar manages migrations for your Cassandra data stores.
https://github.com/comeara/pillar
MIT License
111 stars 64 forks source link

How to ignore applied scripts? #18

Closed PeterLappo closed 9 years ago

PeterLappo commented 9 years ago

Hi Having trouble with pillar when using it a play app. If I have some scripts already applied how do I add a new one such that the applied ones are ignored and the new ones are applied?

I plan to use this on a continuous integration environment so that I can simply add a script, launch and upgrade, a bit like the play evolutions. https://github.com/typesafehub/playframework/blob/master/framework/src/play-jdbc/src/main/scala/play/api/db/evolutions/Evolutions.scala

Thanks Peter

magro commented 9 years ago

Hi Peter,

you can check out https://github.com/magro/play2-scala-cassandra-sample, just have a look at the global and pillar.Pillar. (it's using an older version of pillar, perhaps you need some small adjustments)

We have also created an sbt plugin: https://github.com/inoio/sbt-pillar-plugin

Cheers, Martin

PeterLappo commented 9 years ago

In fact I cloned that project and changed it to the latest version of Cassandra and pillar. I had to make a number of changes to the play project to make it migrate the faker keyspace. However, after restarting the project pillar tries to reapply the keyspace again and the project fails to load. Deleting the keyspace and starting from fresh didn't help as again the second time the project runs I get the same migration error.

Of course its possible my changes were incorrect which is why I raised this issue. But it looks like pillar will always reapply migrations when the migration time supplied is less than authored time and the applied time is not used in CassandraMigrator. I expected the following behaviour

if script not applied and authored time < supplied (or current time) then apply up script if script applied and authored time < supplied (or current time) then ignore up and down script if script applied and authored time > supplied (or current time) then apply down script

In other words the default is to apply the up script once and the down script if you need to revert.

The play framework evolution code is interesting as it seems to remember failed scripts in case the failed script is fixed and needs to be reapplied.

PeterLappo commented 9 years ago

Hi Martin, Looks like its my bad. Not sure exactly what I did but it was probably a combination of playing around with the dates / descriptions which caused subsequent migrations to fail after restarting. All ok now. Can I suggest an explanation of how the migration works in the readme file e.g. what table it uses and the migration rules? Cheers Peter

magro commented 9 years ago

Great to hear that it's working now! Of course suggestions for improvement are always welcome, I think I can speak for @comeara (project owner) in this case :-) I'd also be happy if you'd like to submit a pull request with your updates for my sample project.

Cheers, Martin

PeterLappo commented 9 years ago

Not sure if replying by email works, but here goes.

Will clean up code and submit pull request.

Also see comments on loading from a jar file. Have gone one step further and load from any resource path on the classpath that matches the requested path. So can have library jars with migration scripts in addition to main project.

Peter

www.smr.co.uk +44 7767 784452

On 2 Nov 2014, at 07:21, Martin Grotzke notifications@github.com wrote:

Great to hear that it's working now! Of course suggestions for improvement are always welcome, I think I can speak for @comeara (project owner) in this case :-) I'd also be happy if you'd like to submit a pull request with your updates for my sample project.

Cheers, Martin

— Reply to this email directly or view it on GitHub.