DropScript functinality breaks the order of scripts execution in the case of continually tables updates

Hi, looks as though new DropScript functinality breaks the order of scripts execution in the case of continually tables updates. The DropScript script corresponfing the first update one is going in the end whereas it should be executed immediatelly after the first update script and before the next update script. Maybe it would be worth starting with initial 01 index, omitting indexless script.

image

Hi, @ilya.rodionov!

  1. Does this problem cause an error while executing the ‘updateDb’ task?
  2. Do you just dislike this order of scripts?
    In the first case, could you send the stack trace of error and the contents of the update scripts?

Hello, Alexander!

Yes, this scripts cannot be applied together since the order is different from the original one, when they were incrementally generated by Studio and run. I ran them in the order which they are supposed to be – everything is ok.

Actually in this particular case something else really look rather strange in scripts - I mean dropping column in lower case and creating the same in uppercase - but anyway this is an another issue, isn’t it?

DropScript_broken_sequnce_example.tar.gz (670 Bytes)

And one more question on scripts naming, perhaps it would be better to split topics. I can’t fingure out what the digit wich goes after date in script names is? And, did you consider adding sort of user or UUID identificator to the end of script names to ease mergeing when two developers are deciding to make change in the same entity? This complicates things, I understand, cause it’s could be a tricky to determine in what order scripts should be applied, by this is the case up to a moment as well.

Yes, this scripts cannot be applied together since the order is different from the original one, when they were incrementally generated by Studio and run…

I would like to receive an error message, because I do not understand the problem. ‘updateDb’ task sorts the scripts by file name, and the order of execution of scripts in your case is correct.

Actually in this particular case something else really look rather strange in scripts - I mean dropping column in lower case and creating the same in uppercase - but anyway this is an another issue, isn’t it?

It is a cosmetic issue. Columns created without quotes are register-insensitive.

And one more question on scripts naming, perhaps it would be better to split topics. …

It’s an interesting idea, we’ll think about it.

No, that’s not a cosmetic issue, I wouldn’t waste my and your time otherwise. Take a look.
Instead of finishing numberless series with DropScript Studio goes to execute 01 an 02, what leads to errors.

image

I mean dropping column in lower case and creating the same in uppercase - it is a cosmetic issue.
Failed update scripts are the serious problem. The problem really exists. We will try to fix it in the next releases.
Issue: https://youtrack.cuba-platform.com/issue/STUDIO-4433

I see. Yes, re-creating doesn’t pose a problem until the data doesn’t exist.
Maybe it’s worth considering to add update table set new_col = old_col when renaming column?
As for the issue, thanks, it will be great.