My dynamoDB table has a GSI which its sort key is composite key. This composite key looks like this: #STATUS#CREATED_AT. The status field can be changed during update action on item, but I noticed even if I change the GSI_sk in primary table, this field doesn't change at all.
e.g.
my Item1 has a field GSI_sk with the value OPEN#1234
I update Item1 which GSI_sk is changed to CLOSED#1234
The GSI_sk remained unchanged (still OPEN#1234) when I queried Item1 again
How to update my item and also update the GSI_sk field?
Related
So I wanted to fetch the last item/row of my dynamodb table but i am not finding resources. My primary key is id having series of incremented numbers such as 1,2,3... for each row respectively.
This is my function.
async function readMessage(){
const params = {
TableName: table,
};
return dynamo.getItem(params).promise();
}
I am not sure as to what i should be adding in my params.
DynamoDB has two types of primary keys:
Partition key – A simple primary key, composed of one attribute known as the partition key.
Partition key and sort key – Referred to as a composite primary key, this type of key is composed of two attributes. The first attribute is the partition key, and the second attribute is the sort key.
When fetching an item by partition key, you need to specify the exact partition key. You cannot fetch the max/min partition key.
Instead, you may want to create a sort key with a timestamp (or the ID if it's a sequential number) and use the sort key to fetch the last item.
Check out the AWS docs on Choosing the Right Partition Key for more info.
The proper way to design a table in DynamoDB is based on its expected access patterns; if this is something you need perhaps you should consider using this id as Sort Key instead of Primary Key and then query the table in descending order while also limiting the amount of items to 1.
If instead you don't want to change the schema of your items and you don't care about making at least two operations to do this you have two, not optimal options:
If none of your items ever gets deleted, just make a count first and use that information to know what's the latest item that was written.
Alternatively, if you could consider keeping a "special" record in your DynamoDB table that is basically a count that gets always incremented/written when one of your "other" items gets written. Upon retrieval you first retrieve the value of this special record and use this info to retrieve the actual one.
The combination of the partition key and sort key, makes the primary key of your item in the dynamoDB, so their combination must be unique, otherwise the item will be overwritten.
In almost all my use-cases, I select the primary key as an object attribute, like the brand, an email or a class and then, for the sort key I select the TimeStamp. So in this way, you always know the partition key, we need it to retrieve the values and then you can query your dynamoDB by making some filters by the sort key. For more extensive examples using Python, check the AWS page: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GettingStarted.Python.04.html, where it shows, how you can query your DynamoDB items.
There is also other ways to define the keys in your Dynamo and for that I advise you to check https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-sort-keys.html
I have the following data structure
item_id String
version String
_id String
data String
_id is simply a UUID to identify the item. There is no need to search for a row by this field yet.
As of now, item_id, an id generated by an external system, is the a primary key. i.e. Given the item_id, I want to be able retrieve version, _id and data from the dynamodb table.
item_id -> (version, _id, data)
Therefore I am setting item_id as the partition key.
I have two questions for future-proofing (evolution of) the above "schema":
In the future, if I want to incorporate version (version number of the item) into the primary key, can I just modify the table and add it to be the partition key?
If I also want to make the data searchable by _id, is it feasible modify the table to assign _id to be the partition key (It is a unique value because it is a UUID) and reassign item_id to be a search key?
I want to avoid creation of new dynamodb table and data migration to create new key structures, because it may lead to down time.
You cannot update primary keys in DynamoDB. From the docs:
You cannot use UpdateItem to update any primary key attributes. Instead, you will need to delete the item, and then use PutItem to create a new item with new attributes.
If you wanted to make data searchable by _id, you could introduce a secondary index with the _id field as the partition key of the index.
For example, let's say your data looked like this:
If you defined a secondary index on _id, the index would look like this (same data as the previous example, just a different logical view):
DynamoDB doesn't currently have any native versioning functionality, so you'll have to incorporate that into your data model. Fortunately, there's lots of discussion about this use case on the web. AWS has a document of DynamoDB "Best Practices", including an example of versioning.
I have Dynamodb table whose primary key is partition key. This table has "created date" column also. I want to query this table to fetch top 100 records in descending order by created date. Query must have -key-condition-expression which will accept primary key of this table and it will always return maximum single record. How can I write to fetch top 100 records?
Have you read the documentation for Dynamo?
It's not an RDBMS...
In order to get more than 1 record out of DDB, you need to have a composite key (hash key + sort key)
Without knowing anything else, it sounds like you'll need to create a global secondary index with a composite key where "created date" is the sort key.
Picking the hash key for your GSI is the harder question...
I have two tables, category (pk) and foreign key table Item(fk).
In item table have itemid, item name,category I'd....and this category I'd is foreign key column with primary table...which is having category I'd, Category name.
And I have relationship between category table as parent and. Item table as child table....category I'd is the relationship between them. When I delete records based on itemid the records should be deleted from the application but maintained at backed level..as I do not want duplicate item...even I have deleted from application.
At Application level I am doing these things with textboxes for and drop down list which should category names.
If I have got you correctly, what you want to do is, maintain the data in the database table even if you delete it from the application interface.
If that is the case, you simply can add a column like 'isDeleted' in both of the tables in the database. In the delete event, just fire the update statement instead of actually deleting the record and set the 'isDeleted' field value to 'True'. At the time of displaying data from the tables, just select the records having 'isDeleted' value equals to 'False'.
I have a table called "orderDetails" which contains 4 fields:
OrderID // (primary key of Orders table)
ItemID // (primary key of Items table)
Amount
IsImportant
the primary key of orderDetails table is composed by the first two fields.
I have in my asp.net site a gridview which shows the order details of a selected order.
I'm trying to update a row in the gridview. the user can update only the Amount, IsImportant fileds.
For all the rows except the first one i'm getting this error when trying to update a row:
The property 'ItemID' is part of the object's key information and
cannot be modified.
I read that it is not possible to update the primary key but this is weird because
I'm not trying to update the primary key, only the rest of the fields
updating the first row in the gridview does succeed.
Thanks!
I'm not sure this is what you're looking for, but try to set the column of the problematic key to visible = false. Because when you do update it basically tries to updates ALL fields which appears on that row.
But it's still weird why the first row's update did succeed.