Alternative default code for migration new fields & latest translated strings

[osarrat]

fixes #1021 "Missing field code in v2.1=>v2.2 migration new fields creation"

[ghost]

I would like not to change already merged migration files to prevent database mess. Can you revert and introduce a new migration file that do only the changes you want? (I guess you will have to redefine the entire migrate_budget_fields).

[osarrat]

Thanks for this feedback.
The change is really minor: it just provides some field codes which are not present. Their won't be any impact for developer databases which might have already pass this script on their database: their data will just miss some facultative field codes for a few fields.
Can't we then keep it like that?

[ghost]

I understand your point but it won't work. Flyway has a strong rule: migration already passed should not be modified: the migration process check all files integrity when booting (via checksum) and will crash everything telling the developer to fix the files. I guess we will have support to do on the mailing-list... people will have to flyway:repair. Adding a new migration file is simple and straightforward and won't raise any failure on the developer side.

Actually, flyway migrations are suitable for physical schema changes but dealing with procedures as its own mechanism in Flyway 4 (we use v3) called repeatable migration that is made for that: it allows you to do things like 1 procedure = 1 file and flyway will detect the file change and re-create the procedure if changed. I think we don't have many procedure so it's not necessary for now... and we lack experiences with that feature so not sure if there is not drawbacks I can't think of.

[osarrat]

I have followed your suggestion, and created a V17 in flyway dir for this new version of the procedure.

I have also added the latest translations.

[osarrat]

Hi @numero-six : flyway-migrate is making this build fail.
Can you tell what I should fix in addition ?

[ghost]

Hi @osarrat

I'm confused... You procedure seems fine to me but it seems that the CREATE TEMPORARY TABLE tmp_migrate_budget_field behave strangely... It seems that it is never dropped even if marked as TEMPORARY. I don't understand why because PostgreSQL is supposed to support that.

Can you try a workaround? Just add

DROP TABLE IF EXISTS tmp_migrate_budget_field;

just before the CREATE TEMPORARY TABLE so we make sure the table creation will work.

[osarrat]

Thanks @numero-six for your tip ! It builds now !