[WIP] Atlas search lookups #325
Conversation
django_mongodb_backend/functions.py
Outdated
|
|
||
| class SearchAutocomplete(SearchExpression): | ||
| search_type = "autocomplete" | ||
| expected_arguments = [("path", str), ("query", str)] |
There was a problem hiding this comment.
The expected_arguments pattern doesn't look nice to me. Is it doable to declare a separately __init__() for each expression.
Also, I'm a bit doubtful we need strict checking of argument type. When we've added that sort of thing in Django, it's often caused problems due to the possibility of duck-typing.
django_mongodb_backend/functions.py
Outdated
| @@ -268,6 +268,162 @@ def trunc_time(self, compiler, connection): | |||
| } | |||
|
|
|||
|
|
|||
| class SearchExpression(Expression): | |||
There was a problem hiding this comment.
I think these are expressions rather than functions. Could you cherry-pick https://github.com/mongodb/django-mongodb-backend/compare/main...timgraham:move-expressions?expand=1 as the first commit of your branch and move these definitions to expressions/search.py?
There was a problem hiding this comment.
Well, the func is defined as an expression and NumericMixin. This kind of function aren't combinable so I decided to part from expression and make a some similar to func. In my point of view, it is a function 😄.
There was a problem hiding this comment.
BTW, it could be moved to expressions. A function is an expression
There was a problem hiding this comment.
I suggested Expression since you inherited from it. I think the distinction between Expression and Func is more clear in SQL. Whichever you feel is most appropriate is probably fine.
There was a problem hiding this comment.
Expression is better, these aren't pure functions, they modify the state of the pipeline.
WaVEV
force-pushed
the
atlas-search-lookups
branch
from
449b6a3 to
ca8a7cf
Compare
This PR adds the initial implementation of the Atlas operator.
Notes
While working on this, I found a few problems:
For example:
autocompleteandequalsrequire a different type of index thanphraseortext.Simplicity was preferred originally, but here we need to define field-level index types to support the required functionality.
Additionally, the way this implementation works gives us a preview of how
annotatesandfilterqueries will be added. They won't differ much from this one.