Skip to content

Add support for optional enum queryables #390

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 10 commits into
base: main
Choose a base branch
from

Conversation

Zaczero
Copy link
Contributor

@Zaczero Zaczero commented Jun 4, 2025

Description:

This enables support for generating "enum" fields for selected queryables. There is also now a concept of optional queryable parameters - so it's possible to indicate enum fields without requiring that field to be present in all collections. This enum generation is very efficient as it's basically an index-only scan.

    "platform": {
      "description": "Satellite platform identifier",
      "title": "Platform",
      "type": "string",
      "enum": [
        "sentinel-2a"
      ]
    },

Other small changes include adding the previously missing get_items_mapping abstract to the base database logic. I also got confused by the existence of "OS_HOST" and "OS_PORT" variables in the Makefile which appear to be unused, so I simply removed them too.

PR Checklist:

  • Code is formatted and linted (run pre-commit run --all-files)
  • Tests pass (run make test)
  • Documentation has been updated to reflect changes, if applicable
  • Changes are added to the changelog

@jonhealy1
Copy link
Collaborator

Hi @Zaczero Looks great - what do you think about adding a test for this?

@jonhealy1
Copy link
Collaborator

Changelog entry

@Zaczero Zaczero force-pushed the queryables-enum branch from e4c69c0 to 92ed789 Compare June 6, 2025 13:55
jonhealy1
jonhealy1 previously approved these changes Jun 6, 2025
Copy link
Collaborator

@jonhealy1 jonhealy1 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me but maybe @jamesfisher-geo or someone else can have a look too.

@jonhealy1 jonhealy1 requested a review from jamesfisher-geo June 6, 2025 15:34
Copy link
Collaborator

@jamesfisher-geo jamesfisher-geo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good! One question in regard to raising a ValueError.

@Zaczero Zaczero force-pushed the queryables-enum branch from 00c34ad to 6900f27 Compare June 8, 2025 05:46
Copy link
Collaborator

@jamesfisher-geo jamesfisher-geo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me

# Arrange
# Enforce instant database refresh
# TODO: Is there a better way to do this?
monkeypatch.setenv("DATABASE_REFRESH", "true")
Copy link
Collaborator

@jonhealy1 jonhealy1 Jun 8, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We shouldn't have to refresh the database in our tests because we add so little data to the db. We could do something like this to refresh as well:

r = await app_client.post(
f"/collections/{collection_id}/items",
json=item_data,
params={"refresh": "true"}
)
r.raise_for_status()

Copy link
Contributor Author

@Zaczero Zaczero Jun 8, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's needed for the tests to pass. After the last item is added, data may not be immediately available for queries (up to a second of delay), which causes tests to be flaky. I don't know a better way to force a refresh, so I just monkey-patched the env config. I tried adding ?refresh=true to the request URL, but that didn't work.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Weird ok

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We do add items in other tests that seem to be available immediately

Copy link
Contributor Author

@Zaczero Zaczero Jun 8, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In my testing, that wasn't the case, so maybe I'm doing something incorrectly? Some tests pass the refresh=True argument to the db directly (https://github.com/search?q=repo%3Astac-utils%2Fstac-fastapi-elasticsearch-opensearch%20refresh%3DTrue&type=code), which achieves the same goal, but here the tests are hitting the final HTTP endpoint for maximum coverage, and I couldn't find a better way to enforce refresh with it.

@jonhealy1
Copy link
Collaborator

It would be nice to document this functionality somewhere as it is potentially very valuable.

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.

3 participants