[core]: Models, containers for items & events #169
Conversation
| # XXX: 'version' feels like it's duplicated between .properties.version | ||
| # and this, for StacItemRecord. Do we want that? Potential for drifting. | ||
| version: Optional[str] |
There was a problem hiding this comment.
@lossyrob when you get a chance, I'm curious about the decision to elevate version to a top-level property of this ItemRecord model.
Actually... I guess I see it now. ItemRecord is a base class for both StacItemRecord and ItemUpdateRecord, and you want to ensure that version is present in the ItemUpdateRecord, so that we can use it in things like get_id. While StacItemRecord might have this in .properties["version"], ItemUpdateRecord wouldn't have anywhere else for it.
There was a problem hiding this comment.
Yeah, for StacItemRecord and ItemUpdateRecord that's the reasoning.
However, we might in the future want documents that are saved as part of the /stac_id partition that isn't specific to a version. Potentially removing from the base and putting version in both StacItemRecord and ItemUpdateRecord would be a good future-proofing move.
In preparation for low-latency, we're adding / updating a handful of models, some of which are persisted to Cosmos DB. This adds the pydantic models for that.
TomAugspurger
force-pushed
the
tom/feature/low-latency-models
branch
from
a9e7b07 to
1e3f977
Compare
| # XXX: 'version' feels like it's duplicated between .properties.version | ||
| # and this, for StacItemRecord. Do we want that? Potential for drifting. | ||
| version: Optional[str] |
There was a problem hiding this comment.
Yeah, for StacItemRecord and ItemUpdateRecord that's the reasoning.
However, we might in the future want documents that are saved as part of the /stac_id partition that isn't specific to a version. Potentially removing from the base and putting version in both StacItemRecord and ItemUpdateRecord would be a good future-proofing move.
| return v | ||
|
|
||
| def get_id(self) -> str: | ||
| version = getattr(self, "version", "") |
There was a problem hiding this comment.
Ugly, but the best way I could think of to convince mypy that this would be OK (normally, I would use a mixin with a typed class attribute, but that conflicts with how pydantic does stuff).
In preparation for low-latency, we're adding / updating a handful of models, some of which are persisted to Cosmos DB.
This PR adds the pydantic models and terraform (to make the Cosmos DB tables) for that.