spring-data-dynamodb | Amazon DynamoDB-based Java data access layer

You can do several things:

A: better for cost/performance but requires a bit of extra work

In your table, create a partition key PK and order key OK as both strings (you can use whatever name you want for the keys of course, this is just an example - my point being, the keys are not in your data model, you have to create them upon insert). When you create your items, don't store them as a one big document but store parents, children and subchildren separately. Each item gets as PK the value parent/child/subchild, and as OK the value that you have in each item's name as it has the right parentname_childname_subchildname kind of inheritance, or you can construct it from each item's parents properties.

Upon retrieval, you can get all subchildren of a given parent for example with an expression such as where PK = subchild and OK begins_with parentname_ which effectively returns all items that are subchilds and that belong to a given parent, no matter what the child is. Il you want to also filter on the child, you can do begins with parentname_childname_. If you want only the children of a parent, you can do where PK = child and OK begins_with parentname_. If you know precisely what child you want, instead of using begins_with you can simply do where PK = child and OK = parentname_childname. And so forth... (I'm using SQL-like syntax for ease of writing/reading but it's easy enough to convert to dynamodb query language). The idea is too differentiate your item's actual attributes and how you retrieve your item. You can create completely bogus keys if it helps you find your items easily!

You may not event need to differentiate the child "levels" in the PK, and you could as well use just a generic value there for similar results. The main objective of this method is to have an order key to use begins_with on in a particular partition key.

The main problem with this method is that once you have all your parents/children/subchildren as in your /parents example, you will have to reconstruct the tree entirely in code. But as far as dynamodb is concerned, this is probably the most optimized solution.

B: easier option using filters, but (much) worse cost/performance

Store each parent in a big document then scan your table with a filter like where item.children[].subchildren[].name = parentname_childname_subchildname. It's not quite as efficient and costs much more, as filters are applied on the results of the query so you are retrieving everything first then filtering only what you want, so you pay for all the items first then cut out those you don't want. It works but it's not great, especially if you want something like 5 items out of 100000.

Main advantage is that for /parents call, you get the whole hierarchy as described. But for subroutes /parents/x/children/... you will need to either reformat the object in your code or query only sub attributes in the projection expression.

C: using local secondary indexes

A bit like solution A where you store items separately, with the same PK for all items but with a local secondary index with 3 different order keys: name_parent, name_child, name_subchild. Then you can query each index separately depending on what you want. For this use case it's better to use LSIs than GSIs for cost optimization, but you are free to implement the same idea with GSIs. It will work just as well (with the same limitations about reformatting parent elements to contain children elements as well).

For setter injection to work, the setter method needs to follow Java bean conventions i.e., there should be setter method called set, here it should be setDataRecordDBItemRepository. Corrected the code and please have a try?

you have to include the dependency

You can create a constant for globalSecondaryIndexName with environment name,

It turned out that spring-data-dynamo v5.1.0 was not compatible with my version of Spring Boot (2.0.0)

Downgrading the spring-data-dynamo library to v5.0.4 fixed my issues.