If I use dictionaryWithObjects:forKeys:, and my array of keys happens to have duplicates, what happens? I presume the last instance of the duplicate key will be the value associated with the key; is that correct?
The docs say:
dictionaryWithObjects:forKeys:
...
This method steps through the objects and keys arrays, creating entries in the new dictionary as it goes.
Since a dictionary can't have multiple entries for the same key, yes, the "steps through" strongly implies that later elements in the initializing arrays will clobber earlier ones.
Related
If two distinct keys have the same value (and say the value is large) does redis store the value twice or will it use a pointer / reference. The way git does ?
Redis stores them as two independent key-value pairs.
If you want to remove the duplication, you have to build an index from multiple keys to a shared value by yourself.
I have a mapping in solidity. How can I check if a key exist in this mapping. Mapping returns the data type default value if I try to access a non existent key.
Is there any graceful way to achieve the same.
There is no way to do it, because if value didn't set, there will be default value (false, 0, etc.). The best way out is to check that the value is different from the default value
There is no other other way to do this than just check if the key in question has a value initialized.
If you need more than that (e.g. to be able to keep track of which keys have values set, count them, list them, etc.) then a fairly common pattern is to maintain an array alongside the mapping, containing the known keys.
That way, when all you want is the value (or to check its existence), you can query the mapping, which is very gas efficient. When you want to do something with the set of known keys, you can interact with the array.
In indexedDB, if the keys are arrays of integers such as [n,0] through [n,m], for operations that involve getting all the records in which the first element of the array key is n or opening a cursor on the same set of records, is there any advantage to using an index on an additonal property that stores n over using a key range?
Reasons to think an index may not be better include that the browser has to maintain the index for each change to the object store, an additional property has to be added to each record to store already stored data n, and little may be gained since the keys in the index will always point to consecutive records in the object store rather than dispersed throughout.
If the number of different values of n are likely no more than 1,000 and for m no more than 50, is using an index superior to a key range?
Thank you.
I guess the purpose of indexedDB is to have object store locally.
It is not sql that you need to update columns in every object.
since you change the object structure (saying by adding property)
it is true that all the objects in the store must be rewriten as you said...
emm well... another option for you is to update the db with another store
which contain somthing similar to forien key in sql or uniqe key which store the other stored objects extentions... and in it every obj item is also supposed to be same structured.
I think this is the point you start to use onupgradeneeded intansively.
I'd like to be sure about something.
Suppose I have a NSArray, with some objects.
Suppose that those objects are observed.
Now, if I create another NSArray with the first one (initWithArray:copyItems:NO), will the observation be untouched ?
And if I create with copying (initWithArray:copyItems:YES), will the observation follow the new objects in the new array ?
Thanks !
The observation is linked to the original objects by their pointers.
If you create a new array without copying then the objects are the same. The observation doesn't change, you just have multiple references to the same objects.
If you create a new array with copying then the objects are different but the original objects still exist in the original array. The observation doesn't change, you are still observing the original objects. The new objects are effectively unrelated and have no observers.
I'm in the middle of writing some Cocoa classes to parse ID3 tags from MP3 files. To make them as easy to use as possible, I'm allowing the option to request a tag by the actual ID3 frame id ("TCON", "TPE1", "TALB", etc.) or an equivalent word/phrase ("genre", "artist", "album", etc.)
To store this data, currently I have a reference class which returns an NSDictionary with the frame id's as keys, and word/phrases as objects. As I need to look up definitions in both directions, currently I have a second method which returns the dictionary 'switched round', so the words/phrases are the keys.
My question is whether there is a better way to represent this data. Ideally there would be something similar to NSDictionary, the difference being that both the keys and the values must be unique, and you could look up both an "objectForKey:" and a "keyForObject:"
I could write a class for this myself, but I may lose some of the efficiency from hash tables as described in the NSDictionary documentation... also I'd rather keep the number of classes as low as possible in the overall implementation.
Any ideas? Cheers.
Funny you should ask this...
Quinn Taylor, the author of the CHDataStructures framework just added a CHBidirectionalDictionary to the framework last week. It allows you to find objects by key, and find keys by object. It's basically a wrapper around two mutable dictionaries, so you're guaranteed the same lookup time as with a regular dictionary.
The only caveat is that both the object and key must both conform to the NSCopying protocol.