dynamodb-toolbox
dynamodb-toolbox copied to clipboard
Entity.query should respect prefix and transform
I'm new to this library and trying to model my data in line with https://www.alexdebrie.com/posts/dynamodb-one-to-many/.
I describe my user ("main" entity) like this:
export const UserEntity = new Entity({
name: "User",
attributes: {
email: {
partitionKey: true,
prefix: "USER#",
transform: (value) => value.toUpperCase(),
},
sk: {
sortKey: true,
transform: (value) => value.toUpperCase(),
default: (data) => `METADATA#${data.email}`,
},
name: {},
},
table: myTable,
});
For .put, this works fine. I put in an item like this:
item = {
email: "[email protected]",
name: "My name",
};
and the library will make everything uppercase, prefix it and default the sk.
However, when I query with the same email, I get 0 items back. Instead, I have to prefix and transform the email address myself (something like USER#${email.toUpperCase()}.
This seems counterintuitive to me. Is there a reason for this behavior or is the transformation part missing from .query ?
Interesting. The query() method is a Table level entity, so it's not aware of the schema of the Entities you are querying. In fact, query() can bring back multiple Entity types and parse them correctly into their schemas based on the __et attribute.
It might be possible to add a conversion using the Entity level alias for query(), but I'll need to think more about how that would work since it should probably only convert the PK.
I guess my thoughts would lead to separate Entity.query() more from Table.query() and have a different call signature.
Something like
entity.query(item, options, params)
which would then assemble a
Table.query(pk, {
beginsWith: "METADATA#",
filters: {
attr: "_et",
eq: "User"
}
})
beginsWith being put together by however many sk components are found in item (in case it's more components than 1 as in the example above).
Would have the following benefits:
- Automatic conversions
- Filter for exact entity (in case others spill over, which you can't really prevent)
I ran into this issue as well, I was expecting prefix to DWIM when querying
Hi, I am facing this issue as well. Any workaround for this or do we just have to pass in the prefix to the query ourselves?
Would like a suggested workaround here as well.