In the last lecture we created our first table using the AWOS gone.
So let's look at some item level operations in this video.
If you work with relational databases before you may have noticed that we did not specify the names
of all the columns are all the item attributes.
This is because unlike relational databases dynamo DBI does not enforce strict schema.
Only the primary key attributes are mandatory and all other attributes including the ones that are used
in the secondary access are optional.
So one item in Dynamo table could have two attributes right and another atom in the same table could
have 10 attributes for example and both would still be valid items as long as they have the primary
key attributes included if any item does not have a value for a secondary index key.
It will simply be excluded from that particular index and will see this in action.
In this video
let's add some data to our lives table.
Click on the items tab.
Click on the Create item button to add data.
We can simply free let the keys and values here and we can use the plus sign on the left to insert apin
or remove an atom insert as an attribute about the current attribute Aben as set after the current attribute
and the Remove will simply remove IDE tribute from the.
If you prefer the Chaisson format you can switch from tree to text and you can edit or pasting some
Jason here.
If you use dynamo DBI Jason checkbox you'll see that Dynamo the beacon works these days and into its
own internal format which includes the data type as the search string is denoted by an uppercase s number
by an upper case n binary by uppercase B and so on set.
Let's add some dummy data.
For a user ID.
I'm just rolling some keys on my keyboard to get some random value.
Same for no tidy
four times.
Dan let's grab the current epoch times down around Unix time stamp dot com and it
and then we also want to add a content attribute to hold the main text of our no
click on Save to save the item and we have one item you can edit the non-key it to be is in line using
the pencil.
I can hear or simply click on the blue hyperlink to edit it in the editor action Stabb has options like
duplicate item added deleted exported to CSB.
And these are pretty much exactly do what they say manage.
TTL is something will cower in the later part of the course.
So I'm going to use the duplicate option to add some more dummy data here.
And we just have to provide a new primary key values and maybe change some other attributes if we like
and we should have a couple of items.
Now I'm going to duplicate an item and this time I'm going to drop the note ID attribute
and one item where I'll drop the category attribute.
Now if you notice these attributes are part of the global and local.
Second the next keywords.
So if we don't get them from any item that particular item will be omitted from the corresponding index.
Let me show you what I am from the dropdown.
Let's select the note Id index.
This is our global secondary index right.
Note ID has the partition key take Star Search and you'll notice that the item with the note id attribute
is not showing up here.
Similarly if we select our local secondary next that has category as the sarky.
You'll notice that the item with no category is not part of this index.
Now let's get back to the primary index are the table index and hit search.
And here we see old items in our table
if we add more columns are more attributes to the items.
The display sometimes gets slightly cluttered so we get hide or show the design columns using the gear
icon on the top right here.
Now let's look at how to blow from reeds.
There are two ways.
Query and can let's select query first we have to specify the index to be used.
We can query using that table index are the primary key or any of the secondary indexes that we created.
Let's use the table index with the operations you must specify the partition key value.
We have to specify the entire partition key and sarky is optional.
In other words what this also means is query operation performs a search within a single partition.
If I say user ID equals this and search
Rishabh see all the matching items.
And since they all have the same partition key they will be stored in the same partition.
By default These will be sorted by the sarky of the selected index and we can switch the sort order
using the sort.
The radio button here
we can also specify as sarky to narrow down our search.
We can't specify sarky in different ways.
For example we can use combatives and operators equal to greater than between and so on.
Similarly if our key is strong for example let's select the category index.
So with string based sarky we have one more option begins with.
So these are different ways we can narrow down our search and mission or we could also specify a filter
or criteria filter criteria as typically is to filter our data.
What conditions are conditions on non-key attributes.
An important thing to remember here is filters are always filters are always applied after performing
the query.
Dynamo divi performs the raid using the specified index criteria and once it has retrieved the data
it filters set according to the filter criteria provided before returning the data to us.
What this means is specifying one or more filters will not affect they are consumed by the particular
read operation.
You still can zoom the same number of hours to use whether you use a filter or you don't.
So filter is just a convenience feature.
So to say let's look at this.
Can operation select scan from the drop down and hit search.
So we select an index and hit search.
And we should see the corresponding data
and since we selected the table index we'll see all the items in the table up to 100 added time
unlike Curti which provides us data from the partitions specified by the partition key scan operation
can provide us data across partitions and just like operations.
We can also specify filters in the same way for our scanner operations as well.
And again the filters get applied only after performing these can serve dynamo IDB performs the read
first and once it has retrieved the data it filters said according to the filter criteria that is specified
before it returns the data to us and since scanner operations perform so chairs across the table partitions
they can use the read capacity and it's very very fast.
And that is the reason we should avoid using scan operations as far as possible.
And Bradford the cruddy operations for our purposes
this is the reason why.
Well our data modeling is very crucial when working with Dynamo D-B we should choose table keys and
indexes ready carefully considering all the different possibilities of the operations that our application
might need to perform now as well as in future.
So we must think ahead of time and also consider any possible future use cases.
So we are not forced to recreate the whole table if any is case arises in future.
That's more or less all about the item level operations in Dannemora maybe in the next lecture.
I'll walk you through the different options we have on these tabs on the dynamo or the console so.
Thank you for your time and I'll see you in the next Vidia in just a few moments.