Skip to content

Prettify OpenAPI filter descriptions for the read-only API - #636

Draft
joshdimanteto wants to merge 1 commit into
developfrom
patrick/read_only_api_prettier
Draft

joshdimanteto wants to merge 1 commit into
developfrom
patrick/read_only_api_prettier

Conversation

@joshdimanteto

Copy link
Copy Markdown
Contributor

DO NO MERGE THIS IN. THIS IS JUST FOR VIEWING

The filter descriptions rendered in the OpenAPI docs were dense single-paragraph blobs, built by .format()-ing pre-baked strings that each caller had to hand-write its field list into. This reworks them into Markdown-formatted descriptions generated by helper functions.

Why this reads better in the docs:

  • Operators are now a bulleted list with one operator per line and its aliases grouped together (neq / ne), instead of a run-on sentence of fifteen comma-separated pairs.
  • Field lists, formats and examples are labelled with bold headings (Queryable fields:, Format:, Example:) so a reader can find the bit they need without parsing the whole paragraph.
  • Field names and operators are rendered as inline code spans rather than 'single quotes', so they stand out against prose.
  • The where description now includes a concrete worked example built from the entity's first queryable field.
  • Added the missing nilike operator and documented the isnull true/false semantics, which the old text left unexplained.

Why this is nicer to maintain:

  • WHERE_DESCRIPTION.format(queryable_fields="'a', 'b', and 'c'") is replaced by where_description(ENTITY_QUERYABLE_FIELDS). Callers now declare their fields as a tuple of plain names and the formatting (quoting, comma joining) happens in one place.
  • That also fixes a latent bug in investigation.py, where the queryable field list had a stray trailing comma and was being passed as a tuple, so the docs rendered the Python tuple repr instead of the field list.
  • skip, limit and distinct descriptions are pulled out into module-level constants alongside the others, so all the filter copy lives in common.py rather than being scattered inline.

The prettifying pass here was done by Claude.

DO NO MERGE THIS IN. THIS IS JUST FOR VIEWING

The filter descriptions rendered in the OpenAPI docs were dense
single-paragraph blobs, built by `.format()`-ing pre-baked strings that
each caller had to hand-write its field list into. This reworks them
into Markdown-formatted descriptions generated by helper functions.

Why this reads better in the docs:

- Operators are now a bulleted list with one operator per line and its
  aliases grouped together (`neq` / `ne`), instead of a run-on sentence
  of fifteen comma-separated pairs.
- Field lists, formats and examples are labelled with bold headings
  (**Queryable fields:**, **Format:**, **Example:**) so a reader can
  find the bit they need without parsing the whole paragraph.
- Field names and operators are rendered as inline code spans rather
  than 'single quotes', so they stand out against prose.
- The `where` description now includes a concrete worked example built
  from the entity's first queryable field.
- Added the missing `nilike` operator and documented the `isnull`
  true/false semantics, which the old text left unexplained.

Why this is nicer to maintain:

- `WHERE_DESCRIPTION.format(queryable_fields="'a', 'b', and 'c'")` is
  replaced by `where_description(ENTITY_QUERYABLE_FIELDS)`. Callers now
  declare their fields as a tuple of plain names and the formatting
  (quoting, comma joining) happens in one place.
- That also fixes a latent bug in investigation.py, where the queryable
  field list had a stray trailing comma and was being passed as a tuple,
  so the docs rendered the Python tuple repr instead of the field list.
- `skip`, `limit` and `distinct` descriptions are pulled out into
  module-level constants alongside the others, so all the filter copy
  lives in common.py rather than being scattered inline.

The prettifying pass here was done by Claude.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Base automatically changed from patrick/read_only_api to develop September 10, 2026 13:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant