Adding "and", "not", and "or" to ContentManager search()

[shaqq]

Link to search method

The best thing I could come with is that we pass an associative array.

For example, if we wanted to search for the South Park movie,

tags = [
{
'items': ['south-park', 'film'], 
'type':'and'
}, 
{
'items':['tv'], 
'type': 'not'
}
]
Content.objects.search(tags=tags)

And we would apply those filters accordingly.

But, then again, how much cleaner is this than:

Content.objects.search().filter(**{
'tags.slug':['south-park','film'], 
'must':True
}).filter(**{
'tags.slug': ['tv'], 
'must_not':True
})

[shaqq]

The other idea I had was that we append the "and", "or", or "not" to the end of the array. And then if we need anything more complex, we resort to manually adding filters. Like so:

tags = ['south-park', 'film', 'and']
Content.objects.search(tags=tags).filter(**{'tags.slug':'tv', 'must_not':True})

[shaqq]

adding @awentzonline and @csinchok, when you guys get a chance.

[csinchok]

There are a couple issues here. One is the **{"tags.slug": "whatever"} syntax, which admittedly sucks ass. This could be made a little nicer by allowing elasticutils to traverse objects, like in Django (Content.objects.filter(tag__slug="whatever").

For more advanced boolean logic, I think we'd probably want to use "Q" style objects, like in the Django queryset code. I think that just passing dictionaries is a little too raw. At that point, we could just be using normal Elasticutils stuff.

The other issue here is the complication of queries vs. filters. While there are some slight caching differences, unless we want facets, we can just use queries, and not filters.

[shaqq]

Yeah, ultimately the ideal option would be to make elasticutils "better," instead of having a workaround.