Replace dict with new hashtable: hash datatype #1502
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## unstable #1502 +/- ##
============================================
- Coverage 70.93% 70.92% -0.01%
============================================
Files 120 120
Lines 64981 64988 +7
============================================
- Hits 46095 46094 -1
- Misses 18886 18894 +8
|
SoftlyRaining
changed the title
There was a problem hiding this comment.
I skimmed through it. I looks strait-forward. The only material thing to focus on seems to be the hashTypeEntry abstraction.
It would be good to have a clear abstraction and separation, even within t_hash.c, so we don't have too many direct accesses into the hashTypeEntry internals. It will help us later when we want to add things like TTL and embedded value.
SoftlyRaining
force-pushed
the
hash-datatype
branch
2 times, most recently
from
61772d3 to
d357204
Compare
Signed-off-by: Rain Valentine <[email protected]>
…eld/value pairs Signed-off-by: Rain Valentine <[email protected]>
SoftlyRaining
force-pushed
the
hash-datatype
branch
from
d357204 to
bc7d761
Compare
SoftlyRaining
changed the title
zuiderkwast
added
release-notes
src/t_hash.c
Outdated
| /* takes ownership of value, does not take ownership of field */ | ||
| hashTypeEntry *hashTypeCreateEntry(const sds field, sds value) { |
There was a problem hiding this comment.
-
const sdsis meaningless. Is it time to introduce theconst_sdstypedef in sds.h now? -
Take ownership of field but not value seems asymmetrical, but anything else is suboptimal, right? That's what we do for keys too IIRC. It's OK.
-
Shall we add a comment for the entry API, like the one below for the hash type API?
/*-----------------------------------------------------------------------------
* Hash entry API
*----------------------------------------------------------------------------*/
There was a problem hiding this comment.
I agree with you, let's not introduce const_sds in this change. I'll remove the const here - it does not mean const char* as I intended when I wrote it.
I'll add the comment header, that's a good idea :)
| sds hashTypeEntryGetField(const hashTypeEntry *entry) { | ||
| const unsigned char *field = entry->field_data + entry->field_offset; | ||
| return (sds)field; |
There was a problem hiding this comment.
This (and the GetValue) should probably return const_sds if we add that type.
| if (withvalues) value = hashTypeCurrentObjectNewSds(&hi, OBJ_HASH_VALUE); | ||
| ret = dictAdd(d, key, value); | ||
| ret = dictAdd(d, field, value); |
There was a problem hiding this comment.
Follow-up: Let's replace this sdsReplyDictType with a hashtable.
| @@ -1069,25 +1116,25 @@ void hrandfieldWithCountCommand(client *c, long l, int withvalues) { | |||
| else { | |||
| /* Hashtable encoding (generic implementation) */ | |||
| unsigned long added = 0; | |||
| listpackEntry key, value; | |||
| listpackEntry field, value; | |||
| dict *d = dictCreate(&hashDictType); | |||
There was a problem hiding this comment.
Follow-up: Let's replace this dict with a hashtable. Then we can delete that dict type.
Signed-off-by: Rain Valentine <[email protected]>
SoftlyRaining
force-pushed
the
hash-datatype
branch
from
0092f20 to
70c9d6e
Compare
This PR replaces dict with the new hashtable data structure in the HASH datatype. There is a new struct for hashtable items which contains a pointer to value sds string and the embedded key sds string. These values were previously stored in dictEntry. This structure is kept opaque so we can easily add small value embedding or other optimizations in the future. closes valkey-io#1095 --------- Signed-off-by: Rain Valentine <[email protected]> Signed-off-by: proost <[email protected]>
This PR replaces dict with the new hashtable data structure in the HASH datatype. There is a new struct for hashtable items which contains a pointer to value sds string and the embedded key sds string. These values were previously stored in dictEntry. This structure is kept opaque so we can easily add small value embedding or other optimizations in the future.
closes #1095