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 by the loader while it's doing the loading and when it finishes. 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 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 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 by the loader while it's doing theat each visit state change (e.g when a loading and when it finisheser 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