Handling of context misses for type filters

[davidoj]

#65 introduces default behaviour when filtering attachments with a type filter: an empty context will result in the filter fields being filtered against None, which would usually result in an empty set of attachments (this could be made more robust).

The filter will fail if there is a populated context, but there is a miss on one or more of the type filter fields. In particular, the computed filter will be {'fieldname' : ''}, which raises an error if the field type is not in fact a string.

If I'm reading correctly, the behaviour consistent with wq.app would be to return an empty set of attachments in all such cases.

[S. Andrew Sheppard]

Thanks, I also have other use cases to cover. We should probably do the following:

• Document all common use cases and how they are currently handled by wq.app/wq.db
• Implement unit tests for each case in wq.db
• Determine the desired behavior
• Ensure wq.db implements the required behavior
• Implement unit tests for each case in wq.app
• Ensure wq.app implements the required behavior

I've started a wiki page based on my memory of how everything works. Feel free to add any other scenarios you can think of.

https://github.com/wq/wq/wiki/EAV-Filter-Variants

[davidoj]

I added a few scenarios, mostly concerning filter behaviour on falsy values. I don't know if it's particularly important to support all of these, but it might be nice if they could behave as expected where practical.

It seems reasonable to me to expect an is_active=0 filter to result in attributes with a false value of is_active.

On the other hand, it strikes me as somewhat tricky to distinguish between a context miss (a filter like category={{category}} with context {}) and an explicit filter for attributes with empty category columns (a filter like category={{category}} with context category=). Examples on row 4 & 8 of the wiki table. I'm also not sure that this behaviour is particularly likely to be needed.

[S. Andrew Sheppard]

Thanks, this is helpful. I agree that we should focus on reasonable defaults, but otherwise wait until a clear use case arises for some of the edge cases. For 4 & 8 I think it makes sense to have the empty result be the outcome.

For the next step, I think it will help to have unit tests in place before/while finalizing the desired behavior. This will make it easier to determine what the current behavior actually is. I changed the order of the checklist.

If you want to start a pull request I can provide feedback. You might want to use a dedicated branch for this PR in case there are other changes you want to merge before this one. For wq.db, the tests can probably go in tests/test_custompatterns.py and the various filter settings in tests/patterns_app/serializers.py. You'll have to register each serializer with the router separately, either at the start of each test (with rest.router.register_serializer()) or by registering a separate set of models for each use case.

[S. Andrew Sheppard]

I reimplemented #67 in wq.app, which passed all but one of the scenarios. I fixed that scenario so it looks like this is done. Thanks!