Change Details

For T2310, we want to add a new object type: origin visits updates. Each visit would have multiple updates, but all of these objects are immutable: * origin_visit stores the initial state of the visit * origin_visit_updates are created at each visit state change (e.g when a loader starts or updates a visit). There are two meanings we can give to origin_visit_update: 1. a snapshot of the state of the loading at a given date (ie. all fields are present) 2. a "patch" over the previous update Cons of 1: * More duplication, so possible way more space needed if we start using the `metadata` field of visits (we currently don't) Cons of 2: * harder to implement, especially for the pg storage * less efficient as you may need to read multiple visits (although not that much) * state is not inherently consistent, eg if we're missing an older update (eg. while replaying); although we could add a "pointer" on the previous update to detect when it's missing, and temporarily return an error

For T2310, we want to add a new object type: origin visits status. Each visit would have multiple statuses, but all of these objects are immutable: * origin_visit stores the initial state of the visit * origin_visit_statuses are created at each visit state change (e.g when a loader starts or updates a visit). There are two meanings we can give to origin_visit_status: 1. a snapshot of the state of the loading at a given date (ie. all fields are present) 2. a "patch" over the previous status update Cons of 1: * More duplication, so possible way more space needed if we start using the `metadata` field of visits (we currently don't) Cons of 2: * harder to implement, especially for the pg storage * less efficient as you may need to read multiple visits (although not that much) * state is not inherently consistent, eg if we're missing an older update (eg. while replaying); although we could add a "pointer" on the previous update to detect when it's missing, and temporarily return an error

For T2310, we want to add a new object type: origin visits updatesstatus. Each visit would have multiple updatesstatuses, but all of these objects are immutable: * origin_visit stores the initial state of the visit * origin_visit_updatesstatuses are created at each visit state change (e.g when a loader starts or updates a visit). There are two meanings we can give to origin_visit_update:status: 1. a snapshot of the state of the loading at a given date (ie. all fields are present) 2. a "patch" over the previous status update Cons of 1: * More duplication, so possible way more space needed if we start using the `metadata` field of visits (we currently don't) Cons of 2: * harder to implement, especially for the pg storage * less efficient as you may need to read multiple visits (although not that much) * state is not inherently consistent, eg if we're missing an older update (eg. while replaying); although we could add a "pointer" on the previous update to detect when it's missing, and temporarily return an error