You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm wondering if there is a simpler way to implement this. The example includes a PK, SK, and a GSI also with its own PK and SK. The index is called gsi1pk-gsi2sk-index (btw I think this is a typo and should actually be gsi1pk-gsi1sk-index). This entity design is similar to other examples in the docs. But I'm wondering if this example is as complex just for consistency or if it can be simplified, i.e, the SK and GSI might not be required?
My table will only have one entity, with a PK, and a few attributes one of which I need to also be unique, and so doesn't really require single table design aside from what's needed to implement the unique constraint. I'd like to know if it's possible to simplify the electrodb pattern at all, perhaps in a way similar to the pattern in the AWS blog.
Reminder of what the electrodb "constraint" entity example looks like:
Great topic! Yes I think things can be greatly simplified here! The example you pasted is ultimately just a learning tool; it has more "features" than you might actually need, like the ability to query values by name and the additional fields to generically namespace the value.
Here's an example that's about as stripped down as you can get -- note it assumes your table only as a pk like you mentioned:
Any time you'd want to use it you'd use the create() method to ensure it fails if the value already exists. Let me know if this helps or you have any other questions!
I see a suggested pattern in the docs to implement a unique constraint for non-key attributes: https://electrodb.dev/en/mutations/transact-write/
I'm wondering if there is a simpler way to implement this. The example includes a PK, SK, and a GSI also with its own PK and SK. The index is called
gsi1pk-gsi2sk-index
(btw I think this is a typo and should actually begsi1pk-gsi1sk-index
). This entity design is similar to other examples in the docs. But I'm wondering if this example is as complex just for consistency or if it can be simplified, i.e, the SK and GSI might not be required?An AWS blog describes how to implement unique constraints like so: https://aws.amazon.com/blogs/database/simulating-amazon-dynamodb-unique-constraints-using-transactions/
My table will only have one entity, with a PK, and a few attributes one of which I need to also be unique, and so doesn't really require single table design aside from what's needed to implement the unique constraint. I'd like to know if it's possible to simplify the electrodb pattern at all, perhaps in a way similar to the pattern in the AWS blog.
Reminder of what the electrodb "constraint" entity example looks like:
The text was updated successfully, but these errors were encountered: