Reputation: 3663
Is it possible to get DynamoDB to automatically generate unique IDs when adding new items to a table?
I noticed the Java API mentions @DynamoDBAutoGeneratedKey so I'm assuming there's a way to get this working with PHP as well.
If so, does the application code generate these IDs or is it done on the DynamoDB side?
Upvotes: 53
Views: 54748
Reputation: 1177
No it's not possible and it's by design. You're probably using multi-table design so it makes sense in your scenario but it's not what AWS recommends and not the case for every ddb user.
Since AWS recommends single-table ddb design, it only makes sense that the user pass in the ids based on their use case.
For example, let's say you have a Blog table with Post
and Comment
entities in your table. You would want your ids for each to be p#uuid
and c#uuid
. And your table would look something like this:
PK | SK | Entity |
---|---|---|
p#1 | p#1 | Post |
p#1 | c#1 | Comment |
p#1 | c#2 | Comment |
p#2 | p#2 | Post |
How would ddb automatically know what your ids should be? When you add a second comment to the first post, how would it know to keep the primary key as p#1
and only autogenerate the sort key for your comment to be c#2
?
Almost all ddb sdks have some sort of utility function to generate a unique id. I'm not familiar with PHP too much but I'm sure there's a good way to generate a unique id in PHP as well.
Upvotes: 0
Reputation: 1571
The 2022 answer is here: https://dev.to/prabusah_53/aws-lambda-in-built-uuid-382f
External libraries are no longer needed.
Upvotes: 1
Reputation: 13731
The client can create a (for all intents and purposes) unique ID either by picking a long random id (DynamoDB supports 128-bit integers, for example), or by picking an ID which contains the client's IP address, CPU number, and current time - or something along these lines. The UUID standard even includes a standard way to do this (and you have libraries in various languages to create such UUIDs on the client side), but you don't really need to use a standard. And interesting question is how do you plan to find these items if they have random keys. Or are you planning to use a secondary index?
Upvotes: 1
Reputation: 2293
By using schema based AWS dynamodb data mapper library in Node.js, Hash key (id) will be generated automatically. Auto generated ids are based on uuid v4.
For more details, have a look on following aws package.
Data Mapper package for Javascript
Sample snipet
@table('my_table')
class MyDomainClass {
@autoGeneratedHashKey()
id: string;
@rangeKey({defaultProvider: () => new Date()})
createdAt: Date;
}
Upvotes: 2
Reputation: 2810
While working with dynamodb in javascript with nodejs. I use the npm module uuid to genrate unique key.
Ex:
id=uuid.v1();
refer :uuid npm
Upvotes: 4
Reputation: 64741
Good question - while conceptually possible, this seems not currently available as a DynamoDB API level feature, insofar neither CreateTable nor PutItem refer to such a functionality.
The @DynamoDBAutoGeneratedKey
notation you have noticed is a Java annotation, i.e. syntactic sugar offered by the Java SDK indeed:
An annotation, in the Java computer programming language, is a special form of syntactic metadata that can be added to Java source code.
As such @DynamoDBAutoGeneratedKey
is one of the Amazon DynamoDB Annotations offered as part of the Object Persistence Model within the Java SDK's high-level API (see Using the Object Persistence Model with Amazon DynamoDB):
Marks a hash key or range key property as being auto-generated. The Object Persistence Model will generate a random UUID when saving these attributes. Only String properties can be marked as auto-generated keys.
Upvotes: 38
Reputation: 45
Here is another good method taken from mkyong
http://www.mkyong.com/java/how-to-get-current-timestamps-in-java/
I adjusted his method to get the milliseconds instead of the actual date
java.util.Date date= new java.util.Date();
System.out.println(new Timestamp(date.getTime()).getTime());
Upvotes: -5
Reputation: 77
The approach I'm taking is to use the current timestamp for the hash-key (or the range-key, if using a range-key too). Store the timestamp as an integer, representing the number of milliseconds since the start of the "UNIX epoch" (in the UTC timezone). Many date/time libraries can produce this number for you.
This has the advantage that if you want to have a "creation time" field in your table, your UUID already stores this information. Just call another method in your date/time library to convert the timestamp to a readable format.
(Be sure to handle the exception which will occur if a second item is created in the same table with the same millisecond timestamp; just fall back and retry the operation in that case, with a slightly later, current timestamp.)
For example:
User table
hash-key only: userID (timestamp of the creation of this user).
WidgetAttributes table
hash-key plus range-key.
hash-key: userID (use the userID from the User table of the user to whom the widget belongs). range-key: attribID (use the timestamp of the creation of this widget-attribute).
Now you can run "query" operations on the WidgetAttributes table to get all widget-attributes for a certain user; by using "greater-than-zero" as the query-parameter for the range-key.
Upvotes: -6