-
-
Notifications
You must be signed in to change notification settings - Fork 317
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
Add URI and text filters #1079
Add URI and text filters #1079
Conversation
Note that in this PR the filters endpoint response includes some filters multiple times. This is fixed in #1090. |
Codecov Report
@@ Coverage Diff @@
## master #1079 +/- ##
==========================================
+ Coverage 93.24% 93.37% +0.13%
==========================================
Files 112 112
Lines 4084 4168 +84
==========================================
+ Hits 3808 3892 +84
Misses 276 276
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
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.
A couple of changes requested in individual comments below. I'd also like @mathemancer to take a look at this before merge since it touches the URI type.
Notice that in the issue #413, the
x URI scheme equals y
filter is specified to allow the user to choose from a list of URI schemes. This PR does not implement that.At the same time, I think that scheme suggestions is not an important feature right now, so I propose we create an issue for it and put it off.
I think we should do this, it is important for making the product friendly to non-technical users, who may not know what a URI scheme is.
It could be done somewhat easily. Just add to the relevant parameter a hint like
hint.suggested_values(("http","https","ftp","ftps",...))
.This would require putting some
and
-or
logic into the hint system though, which will be necessary down the road, but maybe not so much now.
I'm not sure why this would need "and
-or
logic", can you elaborate?
# would involve creating an alternative to to_sa_expression: something like to_db_function | ||
# execution engine would see that to_sa_expression is not implemented, and it would look for | ||
# to_db_function. | ||
class RedundantDBFunction(DBFunction): |
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 find this name confusing. Perhaps something like DBFunctionCombination
would be clearer?
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 think DBFunctionCombination can be even more confusing, since a regular DBFunction instance can contain other DBFunction instances as parameters, and thus could be called a combination or supporting combination.
I like "redundant", because it highlights that it's made of DBFunctions that could already be combined together without this particular DBFunction.
I'm open to other names. Maybe SecondaryDBFunction
? That's a bit abstract though. DBFunctionPackage
has the same problem as DBFunctionCombination
, but it goes hand in hand with the abstract unpack
method.
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 like DBFunctionPackage
.
db/functions/redundant.py
Outdated
|
||
class StartsWithCaseInsensitive(RedundantDBFunction): | ||
id = 'starts_with_case_insensitive' | ||
name = 'starts with (case insensitive)' |
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.
If this name is meant to be used in the frontend, please remove (case insensitive)
from the name
parameter.
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.
It is. If the suffix is removed, it will have the same display name as a regular (case-sensitive) starts with
filter: a user won't be able to distinguish the two. Why do you want to make this change?
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.
There shouldn't be a case-sensitive "starts with" in the frontend, only the case insensitive version.
We don't want to overwhelm users with a lot of similar filtering options, it will make finding the filter they want harder. And non-technical users may not know what "case sensitive" refers to.
db/functions/redundant.py
Outdated
|
||
class ContainsCaseInsensitive(RedundantDBFunction): | ||
id = 'contains_case_insensitive' | ||
name = 'contains (case insensitive)' |
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.
Case insensitive comment from above applies here as well.
I wasn't clear enough. These are the options I mentioned:
If this is wanted for alpha, I'll hack something together into a dedicated PR. |
@kgodey @mathemancer note that the changes in the |
Okay, thanks, please do. Option 1 seems easiest. |
Ready for review. I've removed case-sensitive string filters from the filters endpoint. Other requested changes will be submitted as dedicated PR/s. Those changes are:
|
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.
Looks good to me, I'll leave it to @mathemancer to review/merge.
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 mostly just had questions; the only real request is to try to unify the definitions of things like "string-like" "number-like", etc. between the definitions in the db.types.operations.cast
module and the hint building logic.
def sa_call_sql_function(function_name, *parameters): | ||
return getattr(func, function_name)(*parameters) |
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.
Awesome idea.
@@ -225,6 +230,36 @@ def to_sa_expression(*values): | |||
class StartsWith(DBFunction): | |||
id = 'starts_with' | |||
name = 'starts with' | |||
hints = tuple([ |
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'm curious why you went with this syntax rather than just
hints = (
hints.foo(bar),
hings.baz,
)
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 find the shorthand tuple syntax ((x,)
) to be errorprone. Just yesterday I ran into an annoying bug where I had forgotten the trailing comma and what was supposed to be a single-element tuple ended up being just the element. So I try to do the more awkward, but safer tuple([x])
. This is not a very strong preference. After getting bit by this a few times you learn to append a comma to everything, I guess.
@@ -73,7 +77,7 @@ class Literal(DBFunction): | |||
name = 'as literal' | |||
hints = tuple([ | |||
hints.parameter_count(1), | |||
hints.parameter(1, hints.literal), | |||
hints.parameter(0, hints.literal), |
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.
Why this change? (and others like 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.
I wanted to use 1-based indexing, but changed my mind. Everything in Python is 0-based, so I decided to go with the flow.
raise Exception("UnpackabelDBFunction.to_sa_expression should never be used.") | ||
|
||
@abstractmethod | ||
def unpack(self): |
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.
For my own education: Should implementations of this unpack
method recurse "in place"? I.e., if I happen to have a redundant (or whatever we decide for a term) function that's composed of other redundant functions, should the unpack
method call the unpack methods of those functions as well, or should that be left to the caller? I'm not sure since you'd want to avoid having the recursion in multiple places, and _db_function_to_sa_expression
is already recursive.
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 think it's desirable not to have to do manual recursion inside unpack
. I don't immediately recall if I implemented full recursion yet. I think I did, since I was concerned about infinite loops.
string_like_db_types = ( | ||
PostgresType.CHARACTER_VARYING, | ||
PostgresType.CHARACTER, | ||
PostgresType.TEXT, | ||
MathesarCustomType.URI, |
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 sort of info is also in the cast.py
file. Did you consider trying to unify these with those definitions? I ask because it makes me nervous to have this defined in more than one place.
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 didn't notice the duplication. I'll investigate.
@mathemancer could we get this merged? It's the base for a few other PRs. I'll open an issue for the duplicated logic across |
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.
Approving, since I agree we should probably get this merged to unblock downstream PRs. Please don't forget to create the issue about the duplicated definitions of type tags (string-like, number-like, etc.)
@mathemancer the issue for that is here: #1100 |
Fixes #413, Fixes #406
Implements following filters:
Other filters required in #413 and #406 have been implemented in previous PRs.
Technical details
The new filters look like this on the
filters
endpoint:Notice that the Mathesar type
uri
is string-like, just liketext
, so it's allowed wherevertext
is allowed (seecontains
parameters' types for an example). In contrast,uri_authority_contains
first parameter can only beuri
. Same foruri_scheme_equals
.Tests for new filters have been added.
Checklist
Update index.md
).master
branch of the repositoryvisible errors.
Developer Certificate of Origin
Developer Certificate of Origin