Hash key attribute cannot be used as range key of secondary index

[rshan2]

I realize this is probably an edge use case, but I am faced with such a use case :)

The problem arises because the dual use attribute is added twice to the allowedSortProperties List in the AbstractDynamoDBQueryCriteria.buildQueryRequestMethod.

The issue is resolved by changing line 112 of AbstractDynamoDBQueryCriteria from

applySortIfSpecified(queryRequest, allowedSortProperties);

to

applySortIfSpecified(queryRequest, new ArrayList<String>(new HashSet<String>(allowedSortProperties)));

[michaellavelle]

Hi rshan2. Thanks for reporting this issue - finding edge cases like the one you describe is exactly what will help move this snapshot build closer towards a release candidate.
Before I apply the suggested fix I would like to write tests to cover this edge case, but I haven't been able to reproduce this issue in the experiments I've just run - I was in fact able to perform queries on entities with an attribute marked both as @DynamoDBHashKey and @DynamoDBIndexRangeKey, and all seemed to work ok. Could you provide more details about how you are encountering this issue, eg: Is the entity mapping to a hash-only table or hash-and-range ? Is the secondary index global or local? What types of searches cause this issue - are you querying on hash-key/range key, and are you requesting ordered results? How does the issue manifest itself? - is there a stack trace/error, or is the behaviour not what you are expecting? Your help with this is really appreciated - once I can reproduce this error I can start working on the tests and apply the fix. Many thanks, Michael

[michaellavelle]

It looks like I've been able to reproduce this issue now - it seems this happens when searching by global secondary hash key equals condition and global secondary range key non equals condition. ( methods of the form findByIndexHashKeyAndIndexRangeKeyAfter ). Searches on IndexHashKey and IndexRangeKey equality do not seem to have an issue which explains why I was able to perform such searches in my initial attempts to reproduce Are you able to confirm that index-hash-key-equals and index-range-key-non-equals scenario is the scenario in which the issue occurs for you? I've applied your suggested fix and resolved the issue perfectly - many thanks. Are you able to confirm that this has resolved the issue for you? I'm afraid that I did not tag a couple of the commits for this issue correctly - mistakenly checked in one commit under #15 and the other commit is untagged, so just wanted to let you know in case this causes any confusion. Also, FYI, I found a related issue with another edge-case - where the primary hash key attribute is also a global secondary hash hey attribute, which I've now resolved under #18. Thanks again for raising this - do let me know if you encounter any further problems. Cheers, Michael

[rshan2]

Hi Michael,

you've precisely reproduced my scenario. My apologies for lack of clarity and detail. The fix works perfectly and the bonus fix, #18, will also be handy in the quest to find data stuffed into dynamodb.

Thanks for your prompt attention and keep up the great work!

-Bob

On Feb 5, 2014, at 5:03 AM, Michael Lavelle notifications@github.com wrote:

It looks like I've been able to reproduce this issue now - it seems this happens when searching by global secondary hash key equals condition and global secondary range key non equals condition. ( methods of the form findByIndexHashKeyAndIndexRangeKeyAfter ). Searches on IndexHashKey and IndexRangeKey equality do not seem to have an issue which explains why I was able to perform such searches in my initial attempts to reproduce Are you able to confirm that index-hash-key-equals and index-range-key-non-equals scenario is the scenario in which the issue occurs for you? I've applied your suggested fix and resolved the issue perfectly - many thanks. Are you able to confirm that this has resolved the issue for you? I'm afraid that I did not tag a couple of the commits for this issue correctly - mistakenly checked in one commit under #15 and the other commit is untagged, so just wanted to let you know in case this causes any confusion. Also, FYI, I found a related issue with another edge-case - where the primary hash key attribute is also a global secondary hash hey attribute, which I've now resolved under #18. Thanks again for raising this - do let me know if you encounter any further problems. Cheers, Michael

— Reply to this email directly or view it on GitHub.

[michaellavelle]

Cheers Bob - I'm glad you're finding the project useful and the fix worked... all the best, Michael