Ah, great.
Thanks for clarifying that for me.
On Tue, Feb 21, 2017 at 11:44 AM, Daan Hoogland
wrote:
> No Rafael the other way around,
>
> The first time you call it it might change things, but no matter how
> often you call it it will have changed in exactly the same way.
>
> On Tue, Feb 21, 2
No Rafael the other way around,
The first time you call it it might change things, but no matter how
often you call it it will have changed in exactly the same way.
On Tue, Feb 21, 2017 at 5:41 PM, Rafael Weingärtner
wrote:
> I think this might be others doubt as well. Sorry if it seems a naïve/
I think this might be others doubt as well. Sorry if it seems a naïve/silly
question.
By idempotent, I understand something that you can make as many operations
as possible and it does not change (broadly speaking). For example, (in
theory), when you do an HTTP Get requests, the response would be
On Tue, Feb 21, 2017 at 3:19 PM, Marc-Aurèle Brothier wrote:
>
> Daan, the project maintainers should enforce that. I also posted another
> finding that the upgrade path are not identical due to the order in which
> upgrade files are executed, see (https://github.com/apache/
> cloudstack/pull/1768
3531 VENetherlands
> @shapeblue
>
>
>
>
> -Original Message-
> From: Marc-Aurèle Brothier [mailto:ma...@exoscale.ch]
> Sent: 21 February 2017 10:04
> To: dev@cloudstack.apache.org
> Subject: Re: Handling of DB migrations on forks
>
> IMO the database changes
t; > -Original Message-----
> > From: Marc-Aurèle Brothier [mailto:ma...@exoscale.ch]
> > Sent: 21 February 2017 10:04
> > To: dev@cloudstack.apache.org
> > Subject: Re: Handling of DB migrations on forks
> >
> > IMO the database changes should be idempotent
com
> 53 Chandos Place, Covent Garden, Utrecht Utrecht 3531 VENetherlands
> @shapeblue
>
>
>
>
> -Original Message-
> From: Marc-Aurèle Brothier [mailto:ma...@exoscale.ch]
> Sent: 21 February 2017 10:04
> To: dev@cloudstack.apache.org
> Subject: Re: Handling o
[mailto:ma...@exoscale.ch]
Sent: 21 February 2017 10:04
To: dev@cloudstack.apache.org
Subject: Re: Handling of DB migrations on forks
IMO the database changes should be idempotent as much as possible with "CREATE
OR REPLACE VIEW..." "DROP IF EXISTS". For other things like altering
IMO the database changes should be idempotent as much as possible with
"CREATE OR REPLACE VIEW..." "DROP IF EXISTS". For other things like
altering a table, it's more complicated to achieve that in pure SQL.
A good call would be to integrate http://www.liquibase.org/ to manage the
schema and ch
Good strategy and I would make that not a warning but a fatal, as the
resulting ACS version will probably not work.
On Tue, Feb 14, 2017 at 12:16 PM, Wei ZHOU wrote:
> Then you have to create your own branch forked from 4.10.0
>
> In our branch, I moved some table changes (eg ALTER TABLE, CREATE
Then you have to create your own branch forked from 4.10.0
In our branch, I moved some table changes (eg ALTER TABLE, CREATE TABLE)
from schema-.sql
to engine/schema/src/com/cloud/upgrade/dao/UpgradeXXXtoYYY.java.
If SQLException is throwed, then show a warning message instead upgrade
interrup
11 matches
Mail list logo
