-
Notifications
You must be signed in to change notification settings - Fork 174
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add some redis list commands #201
Changes from 1 commit
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -246,6 +246,17 @@ ziplist_rstatus_e ziplist_remove_val(uint32_t *removed, ziplist_p zl, const stru | |
* CALLER MUST MAKE SURE THERE IS ENOUGH MEMORY!!! | ||
*/ | ||
ziplist_rstatus_e ziplist_insert(ziplist_p zl, struct blob *val, int64_t idx); | ||
/* | ||
* trim list down to contain at most count entries, starting at idx. a negative count means | ||
* starting from the end, and gives a list that is non inclusive of idx. | ||
* | ||
* e.g. | ||
* if list contains { 0, 1, 2, 3, 4, 5 }, and we call ziplist_trim(zl, 4, -3), | ||
* the trimmed list will be { 1, 2, 3 }. | ||
* | ||
* if there are fewer than count entries, all entries starting at idx are preserved | ||
*/ | ||
ziplist_rstatus_e ziplist_trim(ziplist_p zl, int64_t idx, int64_t count); | ||
This comment was marked as spam.
Sorry, something went wrong. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I probably haven't thought about this carefully enough either. The most obvious benefit of |
||
ziplist_rstatus_e ziplist_push(ziplist_p zl, struct blob *val); /* a shorthand for insert at idx == nentry */ | ||
/* remove tail & return, if val is NULL it is equivalent to remove at idx -1 */ | ||
ziplist_rstatus_e ziplist_pop(struct blob *val, ziplist_p zl); | ||
|
This comment was marked as spam.
Sorry, something went wrong.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yea, i actually like the original behavior better too. the reason i changes this is that count == 0 for lrem in redis means remove all. i will revert this; perhaps we can move this logic out to protocol if we want to support the redis behavior.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
however, returning error also seems wrong to me. intuitively, it seems like this case should just be a no op
This comment was marked as spam.
Sorry, something went wrong.