Issue 9645

Title
Payment term's PaymentTermLineRelativeDelta does too many migration
Priority
bug
Status
resolved
Nosy list
ced, jcavallo, nicoe, pokoli, reviewbot, roundup-bot
Assigned to
nicoe
Keywords
PostgreSQL, review

Created on 2020-09-28.18:10:25 by nicoe, last changed 1 week ago by roundup-bot.

Messages

New changeset c3857dff642c by Cédric Krier in branch 'default':
Call column_is_type only if column exists
https://hg.tryton.org/tryton-env/rev/c3857dff642c
New changeset 75e1c4e0ae5e by Cédric Krier in branch 'default':
Call column_is_type only if column exists
https://hg.tryton.org/modules/account_invoice/rev/75e1c4e0ae5e
New changeset 6ad96d1bab31 by Nicolas Évrard in branch 'default':
Allow column sql types to be tested from the table handler
https://hg.tryton.org/tryton-env/rev/6ad96d1bab31
New changeset e775cf82255f by Nicolas Évrard in branch 'default':
Allow column sql types to be tested from the table handler
https://hg.tryton.org/trytond/rev/e775cf82255f
New changeset 6675d0caa210 by Nicolas Évrard in branch 'default':
Allow column sql types to be tested from the table handler
https://hg.tryton.org/modules/account_invoice/rev/6675d0caa210
Author: [hidden] (nicoe) Tryton committer
Date: 2020-09-28.23:10:55
* Cédric Krier [septembre 28, 2020 18:14]:
> 
> Cédric Krier <cedric.krier@b2ck.com> added the comment:
> 
> I think it is too complex to manage the column type.
> What about testing by inserting a row with the proper type?

Unfortunately it does not work because postgres is doing an implicit
CAST when inserting a value into a VARCHAR and it's bypassable only by
fiddling with the catalog stuffs.
-- 
Nicolas Évrard - B2CK SPRL
E-mail/Jabber: nicolas.evrard@b2ck.com
Tel: +32 472 54 46 59
Website: http://www.b2ck.com/
Author: [hidden] (ced) Tryton committer Tryton translator
Date: 2020-09-28.18:14:05
I think it is too complex to manage the column type.
What about testing by inserting a row with the proper type?
Author: [hidden] (nicoe) Tryton committer
Date: 2020-09-28.18:10:25
In order to fix issue7962 we introduced a change that drop and recreate the columns month and weekday even if there is no migration to handle.

When executing the migration a great number of time we reach the maximum number of column permitted on a postgresql because postgres never removes the dropped column but hides it: https://nerderati.com/2017/01/03/postgresql-tables-can-have-at-most-1600-columns/

I propose to add to the backend table handler a way to retrieve the column type and change the test to check if the column should be dropped or not.
History
Date User Action Args
2021-04-12 22:01:44roundup-botsetmessages: + msg66523
2021-04-12 22:01:32roundup-botsetmessages: + msg66522
2021-04-12 20:56:29roundup-botsetmessages: + msg66520
2021-04-12 20:56:27roundup-botsetmessages: + msg66519
2021-04-12 20:56:23roundup-botsetmessages: + msg66518
nosy: + roundup-bot
status: testing -> resolved
2021-04-12 19:50:40reviewbotsetmessages: + msg66503
2021-04-11 18:21:50reviewbotsetmessages: + msg66407
2021-04-09 11:14:49reviewbotsetmessages: + msg66209
2021-03-11 11:33:02reviewbotsetmessages: + msg65353
2021-01-06 14:14:33reviewbotsetmessages: + msg63792

Showing 10 items. Show all history (warning: this could be VERY long)