cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rafael Weingärtner <rafaelweingart...@gmail.com>
Subject Re: Handling of DB migrations on forks
Date Tue, 21 Feb 2017 16:41:24 GMT
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 always the
same, and the state of the resource should not change.

Now, regarding SQLs; this SQL for instance “CREATE TABLE XXX…..” is
idempotent for you (as far as I understood reading this thread), right?

And something like “CREATE or REPLACE TABLE XXX…..” would be
non-idempotent. Did I understand it right?

On Tue, Feb 21, 2017 at 11:28 AM, Daan Hoogland <daan.hoogland@gmail.com>
wrote:

> On Tue, Feb 21, 2017 at 3:19 PM, Marc-Aurèle Brothier <marco@exoscale.ch>
> 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)
>
> If you mean refuse PRs containing non-idem-potent sql code yes, but as
> for real work it is all on a voluntary basis, that is someone must
> find it worth the time to encode it. I complete agree with a policy to
> refuse comntaining other creates and drop then as in
>
> > > "CREATE OR REPLACE VIEW..." "DROP IF EXISTS....".
>
> So please feel free to speak up if you catch somebody trying to sneak
> in code like that. They have my -1
>
> --
> Daan
>



-- 
Rafael Weingärtner

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message