-
Notifications
You must be signed in to change notification settings - Fork 54
Description
Describe the bug
I am in the process of moving from the Java ddb mapper to the kotlin one and found when querying on a GSI the ExclusiveStartKey
is missing the primary table's PK
and SK
but correctly includes the GSI's PK
and SK
. As a result queries with non-null ExclusiveStartKey
fail with Exclusive Start Key must have same size as table's key schema
Feels related to the following:
#1594
#1596
Regression Issue
- Select this option if this issue appears to be a regression.
Expected behavior
The correct ExclusiveStartKey
is generated.
Current behavior
The ExclusiveStartKey
is missing the primary table's PK
and SK
Steps to Reproduce
Kotlin - DDB Bean | Java - DDB Bean |
---|---|
|
|
Kotlin - Dao | Java - Dao |
---|---|
|
|
Kotlin Query Request
{
"ExclusiveStartKey": {
"SK": {
"S": "C-2"
},
"type": {
"S": "INVITATION"
}
},
"ExpressionAttributeNames": {
"#k0": "type"
},
"ExpressionAttributeValues": {
":v0": {
"S": "INVITATION"
}
},
"IndexName": "registrationIndex",
"KeyConditionExpression": "#k0 = :v0",
"Limit": 3,
"TableName": "ApplicationTable"
}
Java Query Request
{
"TableName": "ApplicationTable",
"IndexName": "registrationIndex",
"Limit": 3,
"ExclusiveStartKey": {
"type": {
"S": "INVITATION"
},
"SK": {
"S": "C-2"
},
"PK": {
"S": "C-2"
}
},
"KeyConditionExpression": "#AMZN_MAPPED_type = :AMZN_MAPPED_type",
"ExpressionAttributeNames": {
"#AMZN_MAPPED_type": "type"
},
"ExpressionAttributeValues": {
":AMZN_MAPPED_type": {
"S": "INVITATION"
}
}
}
Possible Solution
It is possible this is user error, I have a GSI and didn't want to redefine all the types as you guys did in the cars
vs model
example instead I did:
private val invitationTable: Table.CompositeKey = ddbMapper.getTable(tableName, InvitationSchema)
private val typeToInvitationIdIndex: Index.CompositeKey
init {
val typeToInvitationIdIndexSchema = ItemSchema(
converter = InvitationSchema.converter,
partitionKey = KeySpec.String(Invitation.INVITATION_INDEX_PARTITION_KEY),
sortKey = KeySpec.String(Invitation.INVITATION_INDEX_SECONDARY_SORT_KEY)
)
typeToInvitationIdIndex = invitationTable.getIndex(Invitation.INVITATION_INDEX, typeToInvitationIdIndexSchema)
}
The other thing I considered was that there was some bug due to the fact that my PK
/ SK
overlap between my GSI and primary table. But I did do a sanity check and even with separate keys the generated start key is missing values.
Context
I did all my testing using LocalDDB in docker.
services:
dynamodb-local:
command: "-jar DynamoDBLocal.jar -sharedDb -inMemory"
image: "amazon/dynamodb-local:latest"
container_name: dynamodb-local
ports:
- "8000:8000"
AWS SDK for Kotlin version
1.5.33-beta
Platform (JVM/JS/Native)
JVM
Operating system and version
OSX