Support multi-attribute GSI partition and sort keys

[cluebbehusen]

Closes #202

DynamoDB added support for multi-attribute composite keys on GSIs late last year. This PR adds support for that feature.

Docs: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GSI.DesignPattern.MultiAttributeKeys.html

KeySchema now accepts tuples of KeySpec for hash_key and range_key, with validation enforcing DynamoDB's 1-4 attribute limit per key type. Single KeySpec values still work as before.

MultiHashKey is a new expression class for querying multi-attribute partition keys:

# Table creation
gsi = GlobalSecondaryIndex(
    name="tenant-region-index",
    schema=KeySchema(
        hash_key=(KeySpec("tenant", KeyType.string), KeySpec("region", KeyType.string)),
        range_key=(KeySpec("date", KeyType.string), KeySpec("seq", KeyType.number)),
    ),
    projection=Projection(ProjectionType.all),
    throughput=None,
)

# Querying
async for item in client.query(
    "my-table",
    MultiHashKey(("tenant", "acme"), ("region", "us-east"))
    & RangeKey("date").equals("2025-01-01")
    & RangeKey("seq").gt(0),
    index="tenant-region-index",
):
    pass

Also fixes HashAndRangeKeyCondition missing __and__, which meant chaining multiple RangeKey conditions required explicit parentheses.

[dimaqq]

I'm not the maintainer, but used to work on this codebase.

I think a change like this should come with a new or updated integration test.

[cluebbehusen]

I'm not the maintainer, but used to work on this codebase.

I think a change like this should come with a new or updated integration test.

Thanks, that's a good point! I've added integration tests in the latest commit. They cover various cases that DynamoDB supports.

Unfortunately, not all integration testing backends support this new feature yet. DynamoDB local does, and I validated the tests against that backend. Unfortunately, Scylla and dynalite do not, so I set up the tests to skip on those backends.

FWIW, moto supports this new feature, but I didn't see that as an existing backend. I'd be happy to add that though if desired.

[ojii]

Unfortunately, not all integration testing backends support this new feature yet.

you can use the flavor fixture to skip tests on some implementations.

[cluebbehusen]

Unfortunately, not all integration testing backends support this new feature yet.

you can use the flavor fixture to skip tests on some implementations.

@ojii, I did set up the tests to skip on unsupported backends.

One nuance is that I had to base it off of the backend name rather than flavor. I did this because there is no flavor for DynamoDB local or localstack; they are both other. DynamoDB local works, but localstack does not, so I could not control skipping based on other.

I would be happy to add more granular flavors, but that felt like scope creep on this PR. Let me know if you would prefer expanding flavor though, and I'd be happy to make that change.

[ojii]

I would be happy to add more granular flavors, but that felt like scope creep on this PR. Let me know if you would prefer expanding flavor though, and I'd be happy to make that change.

expanding makes sense. basically I only added different flavors if they were needed because the implementations differed (I think currently we don't use it since all implementations are similar enough for the tests)

[cluebbehusen]

I would be happy to add more granular flavors, but that felt like scope creep on this PR. Let me know if you would prefer expanding flavor though, and I'd be happy to make that change.

expanding makes sense. basically I only added different flavors if they were needed because the implementations differed (I think currently we don't use it since all implementations are similar enough for the tests)

Perfect! I expanded flavor and updated the tests to use that. I removed the implementation_name fixture I had added since it's now unused.