BED-4726 added new ~eq predicate for filtering on strings #808
Conversation
This file contains 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
mvlipka
added
documentation
mvlipka
commented
Aug 22, 2024
|
|
||
| GreaterThanSymbol string = ">" | ||
| GreaterThanOrEqualsSymbol string = ">=" | ||
| LessThanSymbol string = "<" | ||
| LessThanOrEqualsSymbol string = "<=" | ||
| EqualsSymbol string = "=" | ||
| NotEqualsSymbol string = "<>" | ||
| ApproximatelyEqualSymbol string = "ILIKE" |
There was a problem hiding this comment.
ILIKE allows for case insensitive search
mvlipka
commented
Aug 27, 2024
mvlipka
changed the title
definitelynotagoblin
approved these changes
Aug 29, 2024
mistahj67
reviewed
Aug 29, 2024
There was a problem hiding this comment.
this should be v5.16.0 correct? Or is the goal to have this in the upcoming release?
There was a problem hiding this comment.
Probably cutting it close to the next release since we're about to cut the RC.
I'll throw it in for v5.16.0
packages/go/openapi/doc/openapi.json
Outdated
| @@ -13929,7 +13929,7 @@ | |||
| }, | |||
| "api.params.predicate.filter.string": { | |||
| "type": "string", | |||
| "description": "Filter results by column string value. Valid filter predicates are `eq`, `neq`.\n" | |||
| "description": "Filter results by column string value. Valid filter predicates are `eq`, `neq`, `~eq`.\n" | |||
There was a problem hiding this comment.
nit but should ~eq go before ne 🤔
There was a problem hiding this comment.
I can see that, it's related to eq so would be nice to have it read like a cascading
"equals, approximately equals, not equals"
|
|
||
| GreaterThanSymbol string = ">" | ||
| GreaterThanOrEqualsSymbol string = ">=" | ||
| LessThanSymbol string = "<" | ||
| LessThanOrEqualsSymbol string = "<=" | ||
| EqualsSymbol string = "=" | ||
| NotEqualsSymbol string = "<>" | ||
| ApproximatelyEqualSymbol string = "ILIKE" |
… regex parsing of filters, re-ordered predicate.filter.string wording
mistahj67
approved these changes
Aug 29, 2024
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
Description
This change adds the ability to query text columns in our database, if specified to be allowed, for approximately equals.
Motivation and Context
This was created as part of the saved queries improvements as we required the ability to search for saved queries by their description. Previously it was only possible to search text columns for equals and not equals, this would be frustrating as you may only remember a portion of the description that you wrote.
We also added support for text searching the
saved_queries.namecolumn.The
ginindex was added to the relevant columns in order to improve text search performance.https://www.postgresql.org/docs/9.1/textsearch-indexes.html
This PR addresses: BED-4726
How Has This Been Tested?
I created a couple of sample rows in the
saved_queriestableNOTE: all of the queries for this must belong to the user that is performing the API request
I then sent a query to search for a description
We can see here that only one of the descriptions appears
Querying for a description that does not exist:
Querying for a name that returns multiple results:
Querying for a name returns a single result
Querying for a description with spaces in it:
Querying for a name with spaces that contains the term
testin multiple rows, but only returns the case-insensitive matchTesting querying with
%20to represent a space instead of+Testing the existing
eqpredicate works with spacesTesting the existing
neqpredicate works as it did previouslyScreenshots (optional):
Types of changes
Checklist: