feat: add migration metadata to observation schema #280
Conversation
This adds a new field, `migrationMetadata`, which has two sub-fields: - `originalDocument`: the original observation, in case we ever need it - `hypercore`: metadata about the observation in the old Hypercore I considered adding this to the `Common` schema, but I don't think it makes sense there because we won't necessarily be migrating all types, like `CoreOwnership`.
EvanHahn
force-pushed
the
migration-metadata
branch
from
aab0319 to
9e2b017
Compare
EvanHahn
changed the title
This new version adds a new property to the Observation table, `migrationMetadata`. See [`@comapeo/schema` PR 280][0] for details. [0]: digidem/comapeo-schema#280
|
I've reverted this because I think it contains bugs. It seems like the original observation is stored in the protobuf as a Buffer, in JSONSchema it is a hex-encoded buffer, but the decoding logic is trying to stringify the Buffer. This will lead to corrupt data when editing observations. The "raw" format of migrated observations is JSON (this is what is stored in the MLEF), so I'm not sure where we would get the buffer from in the first place. Rather than fix this, which would take a while, I want to revert this quickly so that we don't introduce these breaking changes in any build of comapeo-core. I wonder whether we should store the original doc as JSON / struct on the protobuf. Also, I wonder whether for the case of migrated observation, we should not store it for edits, e.g. when |
This adds a new field,
migrationMetadata, which has two sub-fields:originalDocument: the original observation, in case we ever need ithypercore: metadata about the observation in the old HypercoreI considered adding this to the
Commonschema, but I don't think it makes sense there because we won't necessarily be migrating all types, likeCoreOwnership.