blag commented on PR #25613: URL: https://github.com/apache/airflow/pull/25613#issuecomment-1209769001
I think I'm against this, but I can be argued otherwise. I'm a little skeptical that giving users the flexibility to specify the, effectively, globbing pattern is going to be super useful over just doing a containment search like the existing code does. Since APIs really shouldn't remove features, I kind of think we should wait for a user to request this before implementing it. However, the `_pattern` query param suffix indicates that the user should supply a _pattern_ for a URI, and the existing code just has them specifying a URI fragment, so that's not 100% ideal. But I'm also not a huge fan of putting SQL syntax into query parameters, or making this inconsistent with how [`dag_id_pattern` works](https://github.com/apache/airflow/blob/c954ce2126430ea3ebb56ac0a51a4762fb6d27c3/airflow/api_connexion/endpoints/dag_endpoint.py#L85). I would probably implement something more similar to globbing, and convert `*` at the beginning and/or end of the uri_pattern to `%` on the backend. I do think we should support exact matches though. What if we did something like how google works, and had more fuzzy matching on by default (eg: the current behavior), but allowed users to specify the URL in quotes for an exact match? Example: ``` GET /api/v1/datasets?uri_pattern=s3 # Get all datasets that resolve to an s3 bucket (kinda sorta) GET /api/v1/datasets?uri_pattern=%22s3://...%22 # Get the dataset with URI exactly matching `s3://...` ``` -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
