DynamoDB GSI with range key item count 0 - amazon-web-services

Question

I have a table in DynamoDB that looks like this:
I added a global secondary index on "Category" to the table and it worked fine and gave me the number of items in the table under item count.
I then realized that i actually needed to be able to search for in a particular "Category" but sorted by "UserRating"
So I deleted the GSI and made a new one like this:
This all worked fine I thought, the names where correct the types (string) for Category and (number) for UserRating was correct.
But then after it finished creating the GSI I looked at the console and it is showing item count 0 even though there should be 13 in this testing table as pictured below:
Thanks for your help.

Answer 1

As per Amazon documentation this is being updated approx every 6 hours.
ItemCount - The number of items in the global secondary index. DynamoDB updates this value approximately every six hours. Recent changes might not be reflected in this value.
In my case, even though the console was still showing ItemCount zero and was returning no results for scan/query of the index, I was able to successfully query it from my code.

Answer 2

I think this is more likely to happen when you have a simple type mis-match between the key-schema types and the concrete item types.
From Managing Global Secondary Indexes -
Note
In some cases, DynamoDB will not be able to write data from the table to the index due to index key violations. This can occur if the data type of an attribute value does not match the data type of an index key schema data type, or if the size of an attribute exceeds the maximum length for an index key attribute. Index key violations do not interfere with global secondary index creation; however, when the index becomes ACTIVE, the violating keys will not be present in the index.
DynamoDB provides a standalone tool for finding and resolving these issues. For more information, see Detecting and Correcting Index Key Violations.
By Example
Item looks like:
"Items": [
{
"Timestamp": {
"N": "1542475507"
},
"DevID": {
"S": "slfhioh1234oi23lk23kl4h235pjpo235lnsfvuwerfj2roin2l3rn9fj9f8hwen"
},
"UID": {
"S": "1"
}
}
],
index looks like:
"GlobalSecondaryIndexes": [
{
"IndexName": "UID-Timestamp-index",
"Projection": {
"ProjectionType": "KEYS_ONLY"
},
"ProvisionedThroughput": {
"WriteCapacityUnits": 1,
"ReadCapacityUnits": 1
},
"KeySchema": [
{
"KeyType": "HASH",
"AttributeName": "UID"
},
{
"KeyType": "RANGE",
"AttributeName": "Timestamp"
}
],
}
]
Table has the attribute definitions:
"AttributeDefinitions": [
{
"AttributeName": "Timestamp",
"AttributeType": "S"
},
{
"AttributeName": "UID",
"AttributeType": "S"
}
]
That item will NOT appear in your new index.
It is completely possible to have a mismatch in type ( in this case "S" != "N" ) without it being flagged when created. This makes sense. You may want to do this sort of thing on purpose, but when you do it accidentally - it's not great.

Answer 3

I also had strange behavior (no results) when the index name contains dashes, as in the OP's screenshots. Replacing the dashes with underscores fixed my problem.

Answer 4

Found the answer. I had my read write capacity set to 1 unit for everything while testing as soon as I increased it fixed the error and I could see the items.