In the incoming model release, OriginVisitStatus has a new "type" entry.
We want to ignore it temporarily.
Related to T2443
Differential D4849
Adapt cassandra storage to ignore the new OriginVisitStatus.type field vsellier on Jan 12 2021, 6:29 PM. Authored by
Details
In the incoming model release, OriginVisitStatus has a new "type" entry. Related to T2443 tox
Diff Detail
Event TimelineComment Actions Build has FAILED Patch application report for D4849 (id=17160)Rebasing onto 2b35198d30... Current branch diff-target is up to date. Changes applied before testcommit 68c0cc9b3dfab13b80a415ca55eedbff70f793c2 Author: Vincent SELLIER <vincent.sellier@softwareheritage.org> Date: Tue Jan 12 18:26:04 2021 +0100 Adapt cassandra storage to support the new OriginVisitStatus.type field Depends on D4848 Related to T2443 Link to build: https://jenkins.softwareheritage.org/job/DSTO/job/tests-on-diff/1092/ Comment Actions @olasd suggested this on irc 18:41 <+olasd> instead of D4849, how about changing the BaseRow.from_dict to only consider the fields that are actually expected in that row? 18:42 <+olasd> this would make it ignore future new fields until they're explicitly implemented 18:42 <+olasd> (rather than bomb out every time we introduce a new "backwards compatible but in fact not really" field) And i think we should give it a shot ;) Comment Actions Build is green Patch application report for D4849 (id=17171)Rebasing onto 30945a5890... First, rewinding head to replay your work on top of it... Applying: Adapt cassandra storage to ignore the new OriginVisitStatus.type field Changes applied before testcommit ea21d246879484cc7cb4a3905e5eeaaaab151a30 Author: Vincent SELLIER <vincent.sellier@softwareheritage.org> Date: Tue Jan 12 18:26:04 2021 +0100 Adapt cassandra storage to ignore the new OriginVisitStatus.type field Depends on D4848 Related to T2443 See https://jenkins.softwareheritage.org/job/DSTO/job/tests-on-diff/1097/ for more details. Comment Actions Here's my suggestion, more explicitly. The main drawback is that it hides potential data retention problems until later runtime, so the function should probably implement a warning so that we don't think we've stored some data and then didn't. All in all I don't know if making this more generic is worth the flexibility/risk.
Comment Actions
Thanks for the suggestion. As it's needed only once for a "short" period of time, we'll keep the explicit version though. |