Return-Path: X-Original-To: apmail-incubator-cloudstack-dev-archive@minotaur.apache.org Delivered-To: apmail-incubator-cloudstack-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id EA43CEAED for ; Sun, 24 Feb 2013 03:31:35 +0000 (UTC) Received: (qmail 44821 invoked by uid 500); 24 Feb 2013 03:31:35 -0000 Delivered-To: apmail-incubator-cloudstack-dev-archive@incubator.apache.org Received: (qmail 44515 invoked by uid 500); 24 Feb 2013 03:31:34 -0000 Mailing-List: contact cloudstack-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: cloudstack-dev@incubator.apache.org Delivered-To: mailing list cloudstack-dev@incubator.apache.org Received: (qmail 44487 invoked by uid 99); 24 Feb 2013 03:31:33 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 24 Feb 2013 03:31:33 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of Alex.Huang@citrix.com designates 66.165.176.63 as permitted sender) Received: from [66.165.176.63] (HELO SMTP02.CITRIX.COM) (66.165.176.63) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 24 Feb 2013 03:31:28 +0000 X-IronPort-AV: E=Sophos;i="4.84,726,1355097600"; d="scan'208";a="8772569" Received: from sjcpmailmx01.citrite.net ([10.216.14.74]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 24 Feb 2013 03:31:06 +0000 Received: from SJCPMAILBOX01.citrite.net ([10.216.4.72]) by SJCPMAILMX01.citrite.net ([10.216.14.74]) with mapi; Sat, 23 Feb 2013 19:31:06 -0800 From: Alex Huang To: "cloudstack-dev@incubator.apache.org" Date: Sat, 23 Feb 2013 19:31:06 -0800 Subject: RE: Upgrade path for db Thread-Topic: Upgrade path for db Thread-Index: Ac4RhoIc+/FQmC8mSqawquQaiyTZqAAAcT8ZAC23nlA= Message-ID: References: <93099572B72EB341B81A644E134F240B012F750D7A92@SJCPMAILBOX01.citrite.net> <93099572B72EB341B81A644E134F240B012F7592C99C@SJCPMAILBOX01.citrite.net> <93099572B72EB341B81A644E134F240B012F7592C9A5@SJCPMAILBOX01.citrite.net>, <031222CBCF33214AB2EB4ABA279428A3012CABCF83AC@SJCPMAILBOX01.citrite.net> In-Reply-To: <031222CBCF33214AB2EB4ABA279428A3012CABCF83AC@SJCPMAILBOX01.citrite.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Virus-Checked: Checked by ClamAV on apache.org I reverted 5b760f903f1a3145f62d05c1d3c142b710248026 again. It all works no= w. --Alex > -----Original Message----- > From: Min Chen [mailto:min.chen@citrix.com] > Sent: Friday, February 22, 2013 9:46 PM > To: cloudstack-dev@incubator.apache.org > Subject: RE: Upgrade path for db >=20 > My last commit 5b760f903f1a3145f62d05c1d3c142b710248026 is reverted in > master. To conclude this thread, this is not an issue for developer. Just > previous db behavior is changed a bit. Previously, after running deployDB= , we > will be able to see all db schema created for the branch we work on. Now > with new db sql reorganization, we will only be able to see all db schema > created after running MS first time. >=20 > -min > ________________________________________ > From: Min Chen [min.chen@citrix.com] > Sent: Friday, February 22, 2013 9:27 PM > To: cloudstack-dev@incubator.apache.org > Cc: cloudstack-dev@incubator.apache.org > Subject: Re: Upgrade path for db >=20 > Hi vijay, >=20 > As I mentioned in my previous email, the commit didn't completely fi= x the > problem, which requires a manual workaround to copy db folder before > running deploy db. I checked it in to unblock you. Since now we realized = that > starting MS can fix the db problem, I will revert my commit. >=20 > -min >=20 > Sent from my iPhone >=20 > On Feb 22, 2013, at 7:07 PM, "Vijayendra Bhamidipati" > wrote: >=20 > > I spoke too soon - I hadn't realized I was in another branch when my se= tup > worked, and the branch didn't have your fix.. now on master, I actually a= m > hitting the exception you mentioned (of not finding the scripts) with the= fix > in place and if I revert it, I'm not seeing it anymore.. any chance you m= ay be > missing something else in your setup?? > > > > Regards, > > Vijay > > > > -----Original Message----- > > From: Vijayendra Bhamidipati > > [mailto:vijayendra.bhamidipati@citrix.com] > > Sent: Friday, February 22, 2013 6:36 PM > > To: cloudstack-dev@incubator.apache.org > > Subject: RE: Upgrade path for db > > > > Hi Min! > > > > Actually I just tried this out and it did invoke the upgrade scripts wh= en I ran > the jetty server to bring up the mgmt. server.. I hadn't copied over the > setup/db/db directory either.. did a fresh db deploy and ran the mgmt. > server.. thanks for fixing the db checker invocation! > > > > Cheers! > > Regards, > > Vijay > > > > > > -----Original Message----- > > From: Min Chen [mailto:min.chen@citrix.com] > > Sent: Friday, February 22, 2013 6:07 PM > > To: cloudstack-dev@incubator.apache.org > > Subject: Re: Upgrade path for db > > > > Yes, I am running into the same issue. The problem is that > > DatabaseCreator is not currently invoking DatabaseUpgradeChecker. I > > just checked in Commit > > 5b760f903f1a3145f62d05c1d3c142b710248026 to address this issue, but sti= ll > have one issue pending solution, that is, how to tell DatabaseCreator to = look > into setup/db folder to look for those sql script in pom.xml. So far we h= aven't > found a solution yet. A temporary workaround is to copy setup/db/db to > your project basedir. > > > > Thanks > > -min > > > > On 2/22/13 3:13 PM, "Vijayendra Bhamidipati" > > wrote: > > > >> How exactly are db upgrade scripts kicked off during a fresh db > >> install on the master branch? > >> > >> When I deploy a fresh db off the ACS master using : mvn -e -P > >> developer -pl developer -Ddeploydb, I don't see the tables specified > >> in setup/db/db/schema-40to410.sql or setup/db/db/schema- > 410to420.sql > >> getting created. > >> > >> The version in the create-schema.sql is 4.0.0 and the same shows up > >> in the newly created db when I do a select * from version; > >> > >> How do I ensure that when deploying a fresh db, the tables specified > >> in schema40to410.sql and schema-410to420.sql get created? > >> > >> Regards, > >> Vijay > >