formdata: store datetimes with timezone (#52057) #1122
Loading…
Reference in New Issue
No description provided.
Delete Branch "wip/52057-timezone"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
82e52ca801
to1f7c1ad721
1f7c1ad721
to65821de6d5
65821de6d5
toa2b4a3712e
a2b4a3712e
tocb2449d65c
cb2449d65c
to495d867952
495d867952
tof1c213cc8e
f1c213cc8e
toada22146eb
ada22146eb
tocbe0463471
cbe0463471
to69a1af4f32
69a1af4f32
tofee94ee30f
fee94ee30f
todb6ff7a6af
db6ff7a6af
tof46d7dea8d
f46d7dea8d
to987af3224f
987af3224f
to0bd6105ace
0bd6105ace
to57c2418fb4
57c2418fb4
todfc2bfb964
@ -412,2 +412,3 @@
assert resp2.json['data'][1] == resp.json['data'][2]
assert resp2.json['data'][2] == resp.json['data'][1]
assert resp2.json['data'][3] == resp.json['data'][2]
assert resp2.json['data'][3] == resp.json['data'][0]
test_user_forms, le test qui échouait parfois, était tout foireux, il récupérait une liste de demandes, puis la même en ordre inversé, et regardait si les demandes (0, 1, 2, 3) correspondaient bien aux demandes (3, 0, 1, 2). Ça n'avait pas de sens mais c'était la plupart du temps le résultat parce que les demandes 0 1 et 2 étaient créées avec le même timestamp. Maintenant qu'on a des timestamps plus précis, l'ordre (3, 2, 1, 0) qui aurait dû être vérifié depuis le début devient systématique.
@ -158,0 +158,4 @@
if d.get('form_receipt_datetime'):
d['form_receipt_datetime'] = make_naive(d['form_receipt_datetime'].replace(microsecond=0))
if d.get('form_last_update_datetime'):
d['form_last_update_datetime'] = make_naive(d['form_last_update_datetime'].replace(microsecond=0))
Pour assurer la compatibilité des API les datetime y sont réduits pour continuer à n'avoir ni timezone, ni microsecondes.
@ -2788,1 +2786,3 @@
'last_update_time': datetime.datetime(*filled.last_update_time[:6]),
'receipt_time': make_naive(filled.receipt_time.replace(microsecond=0))
if filled.receipt_time
else None,
C'est fait à différents endroits, ça aurait pu être fait lors de l'encodage json mais ça aurait alors pris le risque de faire perdre de l'information sur les cas où existaient déjà microsecondes et timezone.
@ -515,3 +515,3 @@
(table_name,),
)
existing_fields = {x[0] for x in cur.fetchall()}
existing_field_types = {x[0]: x[1] for x in cur.fetchall()}
On récupère désomrais également le type des colonnes, pour ensuite faire le changement de type si nécessaire.
@ -539,0 +541,4 @@
if existing_field_types.get('receipt_time') not in (None, 'timestamp with time zone'):
cur.execute(f'ALTER TABLE {table_name} ALTER COLUMN receipt_time SET DATA TYPE timestamptz')
if existing_field_types.get('last_update_time') not in (None, 'timestamp with time zone'):
cur.execute(f'ALTER TABLE {table_name} ALTER COLUMN last_update_time SET DATA TYPE timestamptz')
C'est postgresql qui assure tout le boulot d'ajouter la bonne timezone partout et c'est très bien. (j'ai vérifié on a au niveau de postgresql timezone = 'Europe/Paris' et timezone = 'Indian/Reunion', correctement positionnés).
pourquoi None ?
Quand on récupère la liste des colonnes prsentes, last_update_time peut ne pas encore exister, et j'ai trouvé plus clair d'avoir la même ligne pour les deux colonnes. Une alternative serait d'ajouter last_update_time dès la création de la table mais faire cette partie proprement (exploiter _table_static_fields plutôt que juste dupliquer) demandait une refacto qui dépassait ce ticket.
ok ça se tient
@ -1339,0 +1356,4 @@
'''SELECT table_name FROM information_schema.views
WHERE table_schema = 'public'
AND table_name LIKE %s''',
('wcs\\_carddata\\_view\\_%',),
Je me suis rendu compte qu'en local j'avais des vues sur les fiches, et ça pouvait bloquer le changement de type de colonne, donc ça les dégage.
WIP: formdata: store datetimes with timezone (#52057)to formdata: store datetimes with timezone (#52057)@ -5325,4 +5344,4 @@
for formdef in FormDef.select() + CardDef.select():
do_formdef_tables(formdef, rebuild_views=False, rebuild_global_views=False)
migrate_views(conn, cur)
set_reindex('formdata', 'needed', conn=conn, cur=cur)
migrate_views fait déjà:
Ca fait pas redondant ?
Il me semble qu'en effet désormais, avec l'ajout du drop_views() (qui doit être lancé avant le do_formdef_tables, sinon on peut avoir postgresql en erreur parce qu'on modifie le type d'une colonne reprise dans une vue), cette partie pourrait être réduite à migrate_views().
J'aurais juste la crainte d'une refacto où à un moment le migrate_views ne ferait plus rien parce que feature flag; c'est assez flou mais j'aimerais bien laisser ainsi.
ok
dfc2bfb964
to9e682154f6
9e682154f6
tofb509d951d
fb509d951d
to234427f57e
234427f57e
toe45dd098b3