Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@cassandra.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
Subject: Re: Ordering of schema updates and data modifications
From: Jan Algermissen <jan.algermissen@nordsc.com>
In-Reply-To: <EED9649C-95B1-4D7B-80DA-671ADC93D21B@nordsc.com>
Date: Sun, 18 May 2014 21:27:32 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <C1FCDB0C-8CCE-42EB-B863-43D8AD9EAFAE@nordsc.com>
References: <EED9649C-95B1-4D7B-80DA-671ADC93D21B@nordsc.com>
To: user@cassandra.apache.org


On 18 May 2014, at 10:30, Jan Algermissen <jan.algermissen@nordsc.com> =
wrote:

> Hi,
>=20
> in our project, we apparently have a problem or misunderstanding of =
the relationship between schema changes and data updates.
>=20
> One team is doing automated tests during build and deployment that =
executes data migration tests on a development cluster. In those =
migrations there will be schema changes (adding rows) and subsequent =
data insertions involving these rows.
>=20
> It seems, there are unpredictable times when the update reaches the =
cluster *before* the schema change, causing the tests to fail.
>=20
> What can we do to enforce the schema update to have sufficiently =
happened before the modification is hitting the database?
>=20
> Alternatively, what do others do to handle schema migrations during =
continuous delivery processes.

Surprisingly difficult to find, but here is an example of how to use =
=91describe cluster=92 to check schema propagation:

=
http://www.datastax.com/support-forums/topic/schema-versions-disagree#post=
-7055

Jan


>=20
> Jan