I agree too with this approach. One thing I'm not too familiar with is how the current SQL versioning handled? I know of the schema-xxtoxx sql files but not so much how this are arranged.
Regards Alex Hitchins D: +44 1892 523 587 | S: +44 2036 030 540 | M: +44 7788 423 969 alex.hitch...@shapeblue.com -----Original Message----- From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] Sent: 06 March 2014 09:53 To: dev Cc: Daan Hoogland Subject: Re: [DISCUSS] Checking in code that will break others' environments I totally agree with the incremental approach. I am a fascist at time because i would even want people to add downgrade scripts to any db change they make. Having them not adjust their sql is a good first step, though. On Thu, Mar 6, 2014 at 10:43 AM, Miguel Ferreira <mferre...@schubergphilis.com> wrote: > Hi all, > > I've been looking at the way DB related code (SQL scripts and Java classes) > are updated and what is the impact of those updates on a live cloudstack DB. > By the way, my intention is to support a per-commit DB upgrade of a running > system. > > Anyway, I completely agree that sending an email warning people about changes > that can potentially break running environments is a good thing, and can save > a lot of time and headaches. > I also like the idea of Rajani of using tools to help in the DB migration > process. > However, I would like to put forward another idea: what about making sure > that the changes to the DB (schema and data) are always incremental? > > I mean, once a SQL statement (say A) is added to a script it could be kept as > is, and subsequent modifications cloud be made via new statements (say B), > instead of adapting A. > This would allow people to upgrade their databases to the point they ran > statement A, and afterwards upgrade it again to the point they ran statement > B. > The same principle could also be applied to the Java classes that do data > migration, but maybe there it might be a bit more involved. > > Cheers, > Miguel > > -----Original Message----- > From: Koushik Das [mailto:koushik....@citrix.com] > Sent: donderdag 6 maart 2014 8:25 > To: <dev@cloudstack.apache.org> > Subject: Re: [DISCUSS] Checking in code that will break others' > environments > > Before doing a git pull, I generally check the sql schema changes and run the > delta manually on my existing setup. In most of the cases that works for me > without having to redeploy the db. > > -Koushik > > On 06-Mar-2014, at 11:43 AM, Mike Tutkowski <mike.tutkow...@solidfire.com> > wrote: > >> Yeah, I definitely just meant a "heads up" during development if you >> are going to change something that will break other people's >> environments who update. If these people know in advance, they may >> choose to postpone an update until they are at a better point. >> >> >> On Wed, Mar 5, 2014 at 11:01 PM, Rajani Karuturi >> <rajani.karut...@citrix.com >>> wrote: >> >>> Across versions db migration is taken care. I think this is bound to >>> occur while working on a release, if multiple people work on the >>> same branch with different work-in-progress features. >>> >>> Could we move to flyway or liquibase which can take care of db >>> versioning and migration? >>> >>> >>> ~Rajani >>> >>> >>> >>> On 06-Mar-2014, at 2:08 am, Mike Tutkowski >>> <mike.tutkow...@solidfire.com> >>> wrote: >>> >>>> Yeah, in this case, I'm not referring to erroneous code that breaks >>>> a person's environment (since hopefully the person wouldn't have >>>> knowingly checked in such code), but rather, say, DB-type changes >>>> that improve the system, but break current setups. >>>> >>>> Just a heads-up e-mail with some easily identifiable tag. >>>> >>>> Can anyone think of a good tag for this? It's not always DB >>>> related, so >>> we >>>> might want the tag to be more general. >>>> >>>> >>>> On Wed, Mar 5, 2014 at 1:28 PM, Ian Duffy <i...@ianduffy.ie> wrote: >>>> >>>>> +1 to this. >>>>> >>>>> Having the build suddenly break due to a git pull has been very >>> annoying! >>>>> I usually end up searching through the commit log and doing a >>>>> resets until I find a commit where it works. Then waiting awhile >>>>> until I do a git pull again and hoping the code was fixed. >>>>> >>>>> On 5 March 2014 20:19, Mike Tutkowski >>>>> <mike.tutkow...@solidfire.com> >>>>> wrote: >>>>>> Hi, >>>>>> >>>>>> I encountered a bit of a problem this morning and thought I would >>>>>> bring >>>>> it >>>>>> up for discussion. >>>>>> >>>>>> If we already have a policy around this, please let me know. >>>>>> >>>>>> So, I fetched the latest and rebased my local 4.4 development >>>>>> branch on >>>>> top >>>>>> of master. This all went just fine. >>>>>> >>>>>> When I rebuilt and re-started the CS Management Server, I soon >>> realized I >>>>>> could no longer log in from the GUI. >>>>>> >>>>>> As it turns out, the DB schema had been updated and so my >>>>>> database was >>>>> out >>>>>> of date. The code was querying for fields that didn't exist in my DB. >>>>>> >>>>>> As far as I know, the easiest way to get around this is to >>>>>> destroy my current cloud, run the script to re-build my database, >>>>>> then re-create >>> my >>>>>> cloud, which is somewhat time consuming. >>>>>> >>>>>> Do we have a process in place currently in which we ask those who >>>>>> make >>>>> such >>>>>> changes to send out a notification e-mail to dev@ to give people >>>>>> a >>>>> heads up >>>>>> that updating will lead to such issues? On previous projects, we >>>>>> would >>>>> send >>>>>> out an e-mail and then people could be aware to only update if >>>>>> they >>> were >>>>>> prepared for such re-work. >>>>>> >>>>>> To be clear here, I'm not meaning to pick on anyone in >>> particular...this >>>>>> has happened several times over the course of my CloudStack >>>>>> development >>>>> and >>>>>> I expect that I, too, have checked in such code (without sending >>>>>> out a relevant e-mail) that lead people to have to perform such a >>>>>> complete re-build action un-expectedly. >>>>>> >>>>>> What do people think about this? Maybe we should just add an >>>>>> e-mail tag >>>>> or >>>>>> something and point people to the relevant commit? >>>>>> >>>>>> Thanks! >>>>>> >>>>>> -- >>>>>> *Mike Tutkowski* >>>>>> *Senior CloudStack Developer, SolidFire Inc.* >>>>>> e: mike.tutkow...@solidfire.com >>>>>> o: 303.746.7302 >>>>>> Advancing the way the world uses the >>>>>> cloud<http://solidfire.com/solution/overview/?video=play> >>>>>> *(tm)* >>>>> >>>> >>>> >>>> >>>> -- >>>> *Mike Tutkowski* >>>> *Senior CloudStack Developer, SolidFire Inc.* >>>> e: mike.tutkow...@solidfire.com >>>> o: 303.746.7302 >>>> Advancing the way the world uses the >>>> cloud<http://solidfire.com/solution/overview/?video=play> >>>> *(tm)* >>> >>> >> >> >> -- >> *Mike Tutkowski* >> *Senior CloudStack Developer, SolidFire Inc.* >> e: mike.tutkow...@solidfire.com >> o: 303.746.7302 >> Advancing the way the world uses the >> cloud<http://solidfire.com/solution/overview/?video=play> >> *(tm)* > -- Daan Need Enterprise Grade Support for Apache CloudStack? Our CloudStack Infrastructure Support<http://shapeblue.com/cloudstack-infrastructure-support/> offers the best 24/7 SLA for CloudStack Environments. Apache CloudStack Bootcamp training courses **NEW!** CloudStack 4.2.1 training<http://shapeblue.com/cloudstack-training/> 18th-19th February 2014, Brazil. Classroom<http://shapeblue.com/cloudstack-training/> 17th-23rd March 2014, Region A. Instructor led, On-line<http://shapeblue.com/cloudstack-training/> 24th-28th March 2014, Region B. Instructor led, On-line<http://shapeblue.com/cloudstack-training/> 16th-20th June 2014, Region A. Instructor led, On-line<http://shapeblue.com/cloudstack-training/> 23rd-27th June 2014, Region B. Instructor led, On-line<http://shapeblue.com/cloudstack-training/> This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue is a registered trademark.
