-
Notifications
You must be signed in to change notification settings - Fork 109
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
BED-4726 added new ~eq predicate for filtering on strings #808
Conversation
|
||
GreaterThanSymbol string = ">" | ||
GreaterThanOrEqualsSymbol string = ">=" | ||
LessThanSymbol string = "<" | ||
LessThanOrEqualsSymbol string = "<=" | ||
EqualsSymbol string = "=" | ||
NotEqualsSymbol string = "<>" | ||
ApproximatelyEqualSymbol string = "ILIKE" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ILIKE
allows for case insensitive search
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ILIKE it!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit but should ~eq
go before ne
🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ILIKE it!
… regex parsing of filters, re-ordered predicate.filter.string wording
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for your patience and adding the extra test coverage! 🚀
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.name
column.The
gin
index 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_queries
tableNOTE: 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
test
in multiple rows, but only returns the case-insensitive matchTesting querying with
%20
to represent a space instead of+
Testing the existing
eq
predicate works with spacesTesting the existing
neq
predicate works as it did previouslyScreenshots (optional):
Types of changes
Checklist: