RG config client — CRUD, models and versioned generate methods - #38
RG config client — CRUD, models and versioned generate methods#38carlosfunk wants to merge 4 commits into
Conversation
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
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.
* 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.
Added.
Added the two stubs for this PR. |
cph-datamasque
left a comment
There was a problem hiding this comment.
Approved after one wording change
| """ | ||
| Raised when ruleset generation references an RG config that cannot be found. | ||
| The config does not exist, or has been archived. |
There was a problem hiding this comment.
archived -> deleted
- The admin server now persists a list of validation errors alongside the single-line summary, so surface them as `validation_errors` rather than making callers parse `validation_error` - Correct the `is_valid` docstring, which described the removed asynchronous validation flow
- RG configs take no `version` key, and a label's mask goes under `preset_mask` rather than being mapped to a bare string - The client treats `config_yaml` as an opaque string, so no test caught this; the fixture's only reader is whoever copies it as an example
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).