Mailing-List: contact cloudstack-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cloudstack-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of Alex.Huang@citrix.com
 designates 66.165.176.89 as permitted sender)
From: Alex Huang <Alex.Huang@citrix.com>
To: "cloudstack-dev@incubator.apache.org"
	<cloudstack-dev@incubator.apache.org>
Date: Tue, 26 Feb 2013 13:32:50 -0800
Subject: RE: [ACS][BUG] Master build breaks due to sql updates
Thread-Topic: [ACS][BUG] Master build breaks due to sql updates
Thread-Index: Ac4UYI/vSxeFSV6+Rh65/q6gvUhr1AAAYZYg
Message-ID: 
 <B1DF26ECC0458748AC97CECE2DA98D41013175648DD7@SJCPMAILBOX01.citrite.net>
References: 
 <D2EE6B3265AD864EB3EA4F5C670D256F3224FC@EXDFO01L-CRP-06.webmdhealth.net>
In-Reply-To: 
 <D2EE6B3265AD864EB3EA4F5C670D256F3224FC@EXDFO01L-CRP-06.webmdhealth.net>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Hi Ilya,

I can provide the reason.

CloudStack supports version to version upgrade all the way back to 2.1 days=
.  The typical upgrade means developer adds a statement in the new schema a=
nd adds one in the upgrade.  The problem with this approach is that the dev=
eloper often just writes the new schema and doesn't change the upgrade scri=
pts.  And even if they did, it's not tested.  There's been discussions back=
 in the really early days that this should be changed such that we only use=
 one path, create a schema, apply upgrades.  That's why this has been chang=
ed.

--Alex

> -----Original Message-----
> From: Musayev, Ilya [mailto:imusayev@webmd.net]
> Sent: Tuesday, February 26, 2013 12:41 PM
> To: cloudstack-dev@incubator.apache.org
> Subject: [ACS][BUG] Master build breaks due to sql updates
>=20
> Hi All,
>=20
> Master build breaks, as com.cloud.upgrade.DatabaseUpgradeChecker
> attempts to update/patch a new database with older versions. I'm a bit
> puzzled as to why a fresh installed DB has to be updated. In either way, =
it
> looks like DatabaseUpgradeChecker creates a dir "db" within developer/
> target/db with many update sql files going from versions of 2.x to 4.1
>=20
> Is this an expected behavior to create a fresh database and then layer on=
 the
> sql patches on top? Or did the mechanism that checks if DB update is
> necessary - stopped functioning?
>=20
> To reproduce this issue, initiate a fresh build as of 02/26/13, run throu=
gh
> install and execute db deployment.
>=20
> mvn -P developer -pl developer -Ddeploydb
>=20
> Thanks
> ilya