I am new to using hash table, and I want to know how to change the value of a specific existing key in a hash table. I tried to search but all that came up involved hash map, which I am not familiar with, and which I am not planning to use.
I am not sure whether hash tables only enables inserting and removing values, or whether it enables making a change to an existing key.
Also, please explain to me how to do so. (i.e. .put() means insert. what do I do to change?)
thanks.
Edited because, on reflection, the wording of the question seemed ambiguous, and might have assumed the wrong meaning initially.
You can't change the key, if that's what you meant. The key determines the position of an entry in the hash map/table (by definition), so if you change the key without changing the position, the map/table is now corrupt.
To change the key and change its position is simple: remove the entry under the old key, and add the same entry under the new key.
You can change the value associated with the key. There are several possible approaches. One is to just use put() with the same key to update the value; see the documentation for this. Another is to use entrySet() to get the set of key,value mappings, find the entry for your key, and use setValue() on that entry.
Of course, remove and re-add will also allow you to change the value.
Related
This seems like a relatively common use-case but I can't find any slam-dunk answer. I would like the ability to paginate my results, sorted by a date that is both user-defined and can be modified by the user at any time.
I understand I can add the date to the sort key and delete/re-add the document should the user update the date, or use a secondary index, but neither of these options seem great.
Are there any other options?
Why do neither of those options seem great? Can you elaborate some more?
You want to sort based on the timestamp, as we know DynamoDB sorts items based on a Sort Key. For that reason, to fit your use-case needs you would need to use timestamp as the sort key. If your base table is already using something else as a sort-key then you can create an index, which will allow you to define it.
When you change the key of an indexed item, in this case when the user modifies the timestamp value, DynamoDB handles the underlying delete and write for you. All you need to think about is the update.
I have a use case where DynamoDB is running in production and I need to add a new column IDUpdatedAt which will also be serving as a sort key for one of the GSIs.
I tried a thing in test where my application adds the new rows with IDUpdatedAt, it's working fine but what about the existing rows? How to add the values for those?
Also the new rows will not be added without IDUpdatedAt, but how will the search be impacted for older rows?
PS: IDUpdatedAt is being used as a filter in the application, i.e., user can search for specific ID and can get results sorted by date. That's why IDUpdatedAt is also a part of GSI (sort key).
Please help.
You've got the right idea by adding the field to new items. After all, DynamoDB does not enforce a particular schema outside of the primary key.
This also happens to be a very useful feature, especially when defining a GSI on that attribute; if the atttibute exists on the item, it ends up in the index! For example, imagine modeling an email inbox in DDB where each item represents an email. You could include an attribute 'is_read' and define a GSI using that atttibute.
If the 'is_read' attribute exists on the item, it's in the index. Otherwise, it's not. A cool way to use GSIs to implement filtering.
Pretty neat stuff!
However, there is no way to retroactively update all items with a new attribute other than manually updating each item (or in batches). The equivalent in SQL databases is defining a new column. Unfortunately, an analogous operation in DDB does not exist.
In my SQL-CosmosDB I am not using any queries with WHERE condition other than by a partition key + sort by additional field (so a streamId which is a partition key and event position, as I use Cosmos to store my aggragate roots).
I wonder what will happen if I just exclude all paths from indexing in that collection, except maybe keeping the field I am using for sorting.
Alexander,according to you requirements,i think you could consider setting the index mode as None.Please refer to the explanations in this link.
If a container's indexing policy is set to None, indexing is
effectively disabled on that container. This is commonly used when a
container is used as a pure key-value store without the need for
secondary indexes. It can also help speeding up bulk insert
operations.
Of course,you could choose excluding the root path to selectively include paths that need to be indexed if you have special needs. BTW, as mentioned by #DraganB in the comments,change index policy only affects new records,you could see the statements in this link. So it's better to deliberate at the initial time.
I have a root in firebase like in the I am trying to enable user to delete an item on list. But user can give up his decision. When user give up this decision, I want to insert the deleted item again in the database. But, I want to insert with old firebase generated key, because I am using firebase push keys. Is that a bad practice. How firebase generate these keys? Does it checks every key on db and generate a new one? Is that any possibility, that key marked as removed and generated later for another item? Sorry for the language. It has been hard to express.
EDITED: I want to use the old key because, I am getting the data with orderByKey. I dont want to lose order.
How firebase generate these keys? Does it checks every key on db and generate a new one?
Whenever you use push on a Database Reference, a new data node is generated with a unique key that includes the server timestamp. These keys look like -KiGh_31GA20KabpZBfa.
Because of the timestamp, you can be sure that the given key will be unique, without having to check the other keys inside your database.
Is that any possibility, that key marked as removed and generated later for another item?
No, it is not possible that two keys will collide, regardless of wether one has been removed or not.
But, I want to insert with old firebase generated key, because I am using firebase push keys. Is that a bad practice
Unfortunately, you can't generate the same key twice by just using push. So, it is not possible to delete a node with a given key and then use push to insert it again at the same path with the same key, because push would generate a different and unique key.
Instead of this, if ordering by key is that important to you, and there's a possibility that a deleted node can be reinserted then I would recommend you to do one of the following :-
Either save the key on the client side when it's deleted from the database, and use it when you need to reinsert.
Or , maybe, have a "deleted-keys" path in your database and save the deleted keys there. Of course, with this approach, you'd need to store additional information to identify the data that the key corresponds to.
It all really depends on your use case.
Calling push() will generate a key for you.
If instead you use child(), you can determine they key/path yourself.
ref.child("yourvalue").setValue("setting custom key when pushing new data to firebase database");
https://firebase.googleblog.com/2015/02/the-2120-ways-to-ensure-unique_68.html
I have done research about setValue() and updateChildren(). I have tested both of them to add and update data from firebase database. From what I have learnt that both of them did the same exact thing and did some research about them.
From what I have learnt. The setValue() is used with a class object while updateChildren() is used with a Map or HashMap. Correct me if I'm wrong.
My question is as stated above, what is the difference between setValue() and updateChildren()?
'setValue' method is totally replacing the document (specified reference) with new data.
'updateChildren' method is just updating particular fields or add such fields if they did not exist before.
You often can get the same result using those methods, but actually they are different.
Using an example where your user has fields: Name, Birthday, Favourite Colour.
Set value requires you to set all the fields under the same parent node otherwise they are overwritten with no values and deleted.
However, using updateChildValue, you can specify which field you would like to update without altering other fields. And, if the field doesn't already exist, it will create a new field. This is especially useful if you just want to add a new field under the user like hair colour.