DynamoDB currently does not allow FilterExpression on your GSI hash or sort keys. Hash or sort key should be specified using KeyCondition only. I understand this is made to protect us from making mistakes, but it also removes the ability of doing some pretty good things.
As an example, I am working on a table that has relationships from users to resources. In a simplified example, imagine:
PK|user#SoMeId SK|resourceA#rEsOuRcEiD NAME|-nice-slug-name-
I want to be able to search in "NAME" using "contains", and I would also like to have my list sorted by it, as it is more natural for users than random ids. If I could use a sort key in both KeyExpression and FilterExpression, I could create a GSI using PL/NAME, append prefix to name as well, and have a nice search index.
PK|user#SoMeId SK|resourceA#rEsOuRcEiD NAME|resourceA#-nice-slug-name-
query (PK=user#SoMeId, SK=begins_with(resourceA), INDEX=pk-name-index, FILTER={ name: contains(slug) })
That would be very nice. Judging by I understand DynamoDB works, it seems like this should be completely possible from the technical perspective.
Why don't you guys force an extra argument to enable functionality? Instead of outright banning it, just offer the ability of setting something like AllowKeyFilter=true on the API calls, just to make it an obvious opt-in feature, so no one can complain if they pay more than expected in case they made something wrong?
When I asked this question on the past, I have been told to duplicate fields, but that's just cumbersome. Why not allow it to be used by those that opt-in?
(Continued from https://forums.aws.amazon.com/thread.jspa?threadID=172530)
