-
Notifications
You must be signed in to change notification settings - Fork 570
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
Implement a "between" query operator #1448
Comments
Is this still an active bug? |
This feature request is still active |
I'm going to try to implement this feature |
What is the scale of this project? I'm attempting this as a project for a University class that ends this May. Would all the code for this functionality go within s3query.py and s3resource.py? I'm struggling to understand the underlying architecture. Any advice would be appreciated, thank you. |
Generally yes, the primary implementation would involve primarily s3query.py and s3resource.py, plus some unit tests to verify it. However, I think it should start with a use-case as described above, i.e. a range filter widget that allows the selection of multiple ranges (multi-select drop-down), e.g. extending the existing S3AgeFilter with a multiple-option. Whether this is an appropriate project for the context you mention, is beyond me. I would say yes, and maybe I can mentor you after 24 Feb - but ultimately it is up to your judgment. |
To understand the architecture, you should think of an S3Resource as a database view - i.e. basically a set of related entities plus one or more queries. A query is represented by an S3ResourceQuery instance, which eventually self-translates into a PyDAL Query object plus all necessary joins. A resource holds an array of such resource queries (a.k.a. "filters") in the self.rfilter property (a S3ResourceFilter instance). The query is constructed from the URL query part of a RESTful HTTP request against the resource. This happens during the S3Request construction: S3Request instantiates S3Resource, which instantiates S3ResourceFilter. This process uses the helper classes in s3query.py to process the URL query and construct the S3ResourceQuery array. So, this is the short version - the long version may take a couple of days ;) |
...and to include the use-case part: A filter widget is a Python class (in s3filter.py) that constructs an HTML widget for the user to enter filter criteria in a multi-record perspective (tables, lists, maps etc). This HTML widget is part of the filter form, which is in turn part of the multi-record view. The HTML widget is processed on the client side by a JavaScript (s3.filter.js) that reads the input (i.e. the filter criteria the user chooses/enters), and translates it into a URL query, to then Ajax-reload the table/list/map contents with that URL query. A range filter widget allows the selection of a range (e.g. from-to dates), typically providing two inputs - one for min, and one for max. There is though another variant, where the filter widget would provide a drop-down of pre-defined ranges, e.g. S3AgeFilter - which translates age ranges into a min/max date-of-birth query. And it is this variant of range filtering where it would be highly convenient if multiple (of those pre-defined age) ranges could be chosen. |
Unfortunately I believe implementing this functionality is beyond my ability and the scope of this project. Are there any simpler issues/bugs/tasks that you would recommend working on? Thank you. |
Range queries currently implement a combination of ge+le filter expressions (greater or equal + less or equal), which works well for single-range queries. However, it doesn't support multi-range filtering with the traditional URL query syntax.
In the extended query syntax, it would be possible to specify multiple ranges, but it would be much harder to detect and parse filter defaults.
A possible middle ground could be to implement a between-operator that allows multiple ranges:
The corresponding S3ResourceQuery would accept a tuple (min, max) or a list of such tuples, and translate into a number of OR-ed subqueries accordingly.
This is especially useful with filter widgets with pre-defined ranges (e.g. age groups filter for date of birth field), so that they can support multi-select. It will also simplify the implementation of any kind of range filters (and shorten the expression and thus reduce the amount of data that needs to go over the network).
The text was updated successfully, but these errors were encountered: