Patch endpoints #744
Patch endpoints #744
Conversation
|
I've had to switch from stac-pydantic |
Would a typedDict make more sense? |
Adding default for content_type.
Moving transaction types back to extensions.transaction. Adding literals for content_type. Removing sys check for TypedDict import.
|
@rhysrevans3 should we wait for stac-api-extensions/transaction#14 to be merged/published? |
| def __init__(self, *args, **kwargs): | ||
| """Init function to add 'from' field.""" | ||
| super().__init__(*args, **kwargs) | ||
| self.__setattr__("from", kwargs["from"]) |
There was a problem hiding this comment.
because we're using pydantic model I think we can use Field
class PatchMoveCopy(BaseModel):
"""Move or Copy Operation."""
path: str
op: Literal["move", "copy"]
fromurl: str = Field(alias="from")but then the attribute is .fromurl not .from
There was a problem hiding this comment.
Ah I hadn't seen alias before that looks neater.
I've also added:
model_config = ConfigDict(populate_by_name=True)
which means you can do this:
patch_operation = PatchMoveCopy(**{"path": "hello", "from":"world", "op": "move"})
And overrode the model_dump method so by_alias defaults to True to use the alias in the model dump
patch_operation.model_dump()
#> {'path': 'hello', 'op': 'move', 'from': 'world'}
Not sure if this is the right thing to do or if we should expect people to use:
patch_operation.model_dump(by_alias=True)
|
@rhysrevans3 I'm trying to get a general sense of the For example, I'm looking at https://docs.ogc.org/DRAFTS/20-002.html#update_clause and I don't see reference to the |
|
My understanding is RFC 5789, which the OGC doc references, say a PATCH endpoint should except a set of actions to modify the requested resource. But it doesn't specify what these actions should be. RFC 6902 extends this and specify a set of allowed operations (add, remove, replace, move, copy, test) which is what I have suggested in stac-api-extensions/transaction#14. Currently the README on the transaction extension suggests the PATCH endpoint follows RFC 7396 which accepts a partial json document which it merges with the existing document this might not be the best choice for STAC because of it's handling of |
|
Just to add to @rhysrevans3 's comments, the main issue with supporting only RFC7396 (or RFC7386) is the "magic" behaviour of setting attribute to
Without a fairly complicated scripting command on elastic search, it would not be possible for elastic search to return a _source document that meets the expected result of an explicit RFC6902 gets around this by allowing you to explicitly say "that attribute there, delete it" and not "that attribute there, I'm going to tell you to set it to |
|
@rhysrevans3 The overall looks great, just added one comment about using stac-pydantic base model. As I've asked couple weeks ago, should we wait for stac-api-extensions/transaction#14 to be merged? do you know anyone who could help move this PR forward? |
Ideally yes I think it would be better to have that PR merged first. But my understanding is that RFC 6902 and RFC 7396 are implementations of RFC 5789, which is the current STAC/OGC specification. So this merging this pull still keeps within the current STAC specification. But given @m-mohr comments on that pull request maybe it's best to wait for OGC's opinion. |
Description:
Adds
PATCHendpoints to transaction extension. Adds support for RFC 6902 and RFC 7396. Pivots on headerContent-Typevalue.Related pull request: stac-api-extensions/transaction#14
PR Checklist:
pre-commithooks pass locallymake test)make docs)