Don't demote range key condition to filter condition

[ikonst]

No description provided.

[ikonst]

@jpinner-lyft better?

[jpinner-lyft]

I think this is better -- my only other thought would be now that we're not at tempting to modify the query we could just pass the filter_condition to dynamo un-inspected and let it return any errors. This has the drawback that you don't detect early but would be less code maintenance on our end.

[ikonst]

I had this thought as well (the error checking seemed redundant and we risk being needlessly restrictive) but I didn't venture to check what errors DynamoDB returns in those cases -- that is, maybe this was done because DynamoDB's messaging is confusing? Your suggestion that this checking was introduced only for the demotion's sake seems plausible, though.

[ikonst]

This removes a bunch of code, which is nice.

The server-side errors are:

pynamodb.exceptions.QueryError: Failed to query items: An error occurred (ValidationException) on request (<REQUEST ID>) on table (<TABLE>) when calling the Query operation: ...

1. Using hash key in range key condition:

   KeyConditionExpressions must only contain one condition per key

2. Using non-key in condition:

   Query key condition not supported

3. Using invalid operator (e.g. exists():

   Invalid operator used in KeyConditionExpression: attribute_exists

Would that be clear enough?