Hey Aaron, Thanks for following up on this one.
I guess you're right and in any case, you're unlikely to want two different versions of the code running at the same time. Cheers, Ben On Mon, Dec 23, 2013 at 5:42 PM, Aaron Morton <aa...@thelastpickle.com> wrote: > It depends a little on the nature of the change, but you need some > coordination between the schema change and your code. e.g. add new column, > change code to write to it or add new column, change code to use new column > and not old column, remove old column. > > Cheers > > ----------------- > Aaron Morton > New Zealand > @aaronmorton > > Co-Founder & Principal Consultant > Apache Cassandra Consulting > http://www.thelastpickle.com > > On 19/12/2013, at 3:02 am, Ben Hood <0x6e6...@gmail.com> wrote: > > Hi, > > I was wondering if anybody knows any best practices of how to apply a > schema migration across a cluster. > > I've been reading this article: > > http://www.datastax.com/dev/blog/the-schema-management-renaissance > > to see what is happening under the covers. However the article doesn't > seem to talk about concurrent write access during the migration > process. > > I'm naively assuming that you'd need to block all writes to the > cluster before the migration is started. This is would be firstly > because of potential consistency issues amongst the cluster nodes. But > this would also be because you'd need two versions of your app to > running at the same time. > > Does anybody have any experience with doing this kind of thing? > > Cheers, > > Ben > >
