RG config client — CRUD, models and versioned generate methods#38
RG config client — CRUD, models and versioned generate methods#38carlosfunk wants to merge 2 commits into
Conversation
carlosfunk
changed the title
43f4d05 to
b610a34
Compare
- add RGConfig pydantic model and RGConfigClient mixin: list/get/create/update/delete + defaults yaml - add generate_ruleset_with_rg_config (v3) and file/async/csv variants (v2), mirroring the discovery from_config split - old generate request models reject rg_config and point callers at the new methods - document dependent-RGC behaviour on ruleset library delete/usage APIs
b610a34 to
dd05444
Compare
cph-datamasque
left a comment
cph-datamasque
left a comment
There was a problem hiding this comment.
Mostly minor issues.
Do we want a RGConfigNotFoundError exception type to mirror the handling of 400 responses for other APIs?
Another thing that needs to be done at some point: the docs are out of date and need regenerating. Up to you if you want to do that in this MR, or we could raise a ticket to do it another day.
| def _reject_rg_config(cls, data: Any) -> Any: | ||
| if isinstance(data, dict) and "rg_config" in data: | ||
| raise ValueError( | ||
| "`rg_config` is not accepted by the v2 ruleset-generation request; " |
There was a problem hiding this comment.
In these error messages, don't talk about different versions of the API, as that's meant to be transparent to users of this library.
| def _reject_rg_config(cls, data: Any) -> Any: | ||
| if isinstance(data, dict) and "rg_config" in data: | ||
| raise ValueError( | ||
| "`rg_config` is not accepted by the unversioned file-ruleset-generation request; " |
|
|
||
| @field_validator("connection", mode="before") | ||
| @classmethod | ||
| def _unwrap_connection(cls, value: Any) -> Any: |
There was a problem hiding this comment.
As a separate thought: can we do anything with this meh Any typing on these helpers, and their duplication? Maybe a generic method that is like unwrap[T1, T2](value: Union[T1, T2]) -> Optional[T2] where T1 is the object type and T2 is the id value type, T1 being typedef'd to be a protocol with id field?
|
|
||
| Generation runs asynchronously on the server. | ||
| Poll `get_async_ruleset_generation_task_status` until it returns | ||
| `AsyncRulesetGenerationTaskStatus.finished`, |
There was a problem hiding this comment.
(minor) Does this fit on the previous line to make it easier to read? (Line length can be 120.) Same below at 111.
| """ | ||
| Generate ruleset(s) from a schema discovery CSV report with a selected RG config. | ||
|
|
||
| Like `start_async_ruleset_generation_from_csv`, but posts to the v2 endpoint with a required |
There was a problem hiding this comment.
Semantic breaking, as per CONTRIBUTING.rst.
| (`None` for the server's default RG config). | ||
| """ | ||
|
|
||
| data = generation_request.model_dump(exclude_none=True, mode="json") |
There was a problem hiding this comment.
This pattern is duplicated - worth a shared helper?
| (i.e., it must have been previously created or retrieved from the server). | ||
| """ | ||
|
|
||
| if config.id is None: |
There was a problem hiding this comment.
also need to check config_yaml here - see the DCL API
| No-op if no such config exists. | ||
| """ | ||
|
|
||
| matching = [config for config in self.list_rg_configs() if config.name == name] |
There was a problem hiding this comment.
Can we do a fetch of just the one by name (_get_rg_config_id_by_name) rather than enumerating all of them?
| """ | ||
| Represents a named, persisted YAML ruleset-generation (RG) configuration. | ||
|
|
||
| An RG config maps discovered labels to masks; ruleset generation applies it to a |
* Add `RGConfigNotFoundError`, raised by all four `*_with_rg_config` methods when the server rejects the config id. * Guard `update_rg_config` against a YAML-less config, matching the discovery config library client. * Resolve `delete_rg_config_by_name_if_exists` with the `name_exact` filter instead of enumerating every config. * Fold the duplicated `rg_config` request-body handling into `_post_with_rg_config`. * Drop API version numbers from the `rg_config`-rejection error messages and the changelog. * Apply semantic line breaks to the RG config docstrings and add the missing docs stubs.
2 participants
Adds client support for DataMasque ruleset-generation configs: server-side masks-per-label configs consumed by the versioned generate APIs.
Commits
feat(client): add RG config CRUD and versioned generate methodsWhat's in it
RGConfigpydantic model +RGConfigClientmixin:list/get/create/update/delete+get_default_rg_config_yaml()againstrg/configs/*_from_configsplit:generate_ruleset_with_rg_config(v3),generate_file_ruleset_with_rg_config(v2),start_async_ruleset_generation_with_rg_config(v2),start_async_ruleset_generation_from_csv_with_rg_config(v2). Old methods keep the old endpoints (server default RG config).rg_configand point callers at the new methods.rg_config=Noneis sent as an empty form field; DRF coerces''to null on relational fields (verified end-to-end against a live server).