fix(sqlite): apply _tag/_profile/_security/_source search filters - #482
Open
angela-helios wants to merge 1 commit into
Open
fix(sqlite): apply _tag/_profile/_security/_source search filters#482angela-helios wants to merge 1 commit into
angela-helios wants to merge 1 commit into
Conversation
The sqlite query builder diverted every underscore-prefixed parameter into the special-parameter handler, which only implements _id, _lastUpdated, _text, _content, and _filter and returns None for the rest -- so _tag, _profile, _security, and _source were silently dropped and the search returned the unfiltered result set, while the self link echoed the parameter as if it had been applied. Strict handling did not catch it either: the registry knows these parameters (the spec defines them on Resource with meta.* expressions), so they are not 'unknown'. The extraction side was already correct -- the writer indexes meta.tag, meta.profile, meta.security, and meta.source under their own param_name rows. Only the query side dropped them, and only on sqlite: the postgres builder special-cases just _id/_lastUpdated and routes everything else by type. Sqlite now does the same for these four, letting them take the regular token/uri path against search_index. Closes #474
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #474
The bug
Patient?_tag=…,_profile=…,_security=…(and_source=…) returned the unfiltered result set on sqlite, with the self link echoing the parameter as if it had been applied. The sqlite query builder diverts every_-prefixed parameter into its special-parameter handler, which only implements_id/_lastUpdated/_text/_content/_filterand returnsNonefor everything else — the condition was silently dropped.Prefer: handling=strictcouldn't catch it: the spec registers these parameters onResource(withResource.meta.tagetc. expressions), so they are not "unknown".The fix
The extraction side was already correct — the writer indexes
meta.tag/profile/security/sourceunder their ownparam_namerows, and postgres (which special-cases only_id/_lastUpdatedand routes the rest by type) already filtered correctly. Sqlite now exempts these four from the special-handler diversion so they take the regular token/uri path againstsearch_index. One condition change; no schema or extraction changes.Tests
_tagfilters to the tagged resource, no-match returns empty,_securityby label,_profileby canonical.GET /Patient?_tag=system|codeand?_profile=…over HTTP return only the tagged patient.Note:
_tag:notsemantics ride on #480 (resource-level :not negation) — once both merge,:notcomposes with these params through the same path.