On line 276 above we have this:

if query_keys.include?(source.range_key.to_s)

Seems like we may need a more complete solution than trying to remember to do this to_s conversion everywhere.

@pboling I considered wrapping query hash in OOP stile to incapsulate some logic and hide type conversion but still don't have simple and flexible solution

This bug is too narrow still. The problem is that we are comparing hash keys with strings, and the hash keys may not themselves be strings. Fixing this one instance but leaving the bug in other places where we do comparisons seems like a bad idea to me, as we'll just lose track of the actual problem. I think we should go with a more encompassing solution. Doesn't need to be OOP necessarily, but, why not have new method like query_keys that gives them as string, e.g. query_keys_as_string, and then call that from everywhere we do key comparisons.

@pboling Agree

The simplest solution (and it's already used here in this project) is to convert all user strings to the same type, e.g. symbols. And to have proper tests :).

I will check how we handle and store all user strings like field names, key names, conditions etc to ensue we convert them to symbols.

Actually this bug isn't related to symbol/string comparison. We need to check hash_key: 'value' condition but query_keys contains filtered field names without operators so 'hash_key.contains': 'value' triggers involving index too.