MEMCACHED_APPEND_BY_KEY(3)

💖 memcached_append_by_key — the bestie cut 💖

okay so you're here for memcached_append_by_key(3), from libmemcached-awesome, and honestly? this one is giving "glow up your stored data" energy. we're appending and prepending, no big deal, except it IS a big deal because it's so useful. let's go 🦋

---

✨ NAME ✨

memcached_append_by_key — Appending to or Prepending Data

---

🌸 SYNOPSIS 🌸

first things first, you gotta pull in the header, bestie:

#include <libmemcached-1.0/memcached.h>

and then compile and link with -lmemcached

here's the whole squad of functions, fr fr:

memcached_return_t memcached_prepend(memcached_st *ptr, const char *key,
size_t key_length, const char *value, size_t value_length, time_t
expiration, uint32_t flags)

memcached_return_t memcached_append(memcached_st *ptr, const char *key,
size_t key_length, const char *value, size_t value_length, time_t
expiration, uint32_t flags)

memcached_return_t memcached_prepend_by_key(memcached_st *ptr, const
char *group_key, size_t group_key_length, const char *key, size_t
key_length, const char *value, size_t value_length, time_t expiration,
uint32_t flags)

memcached_return_t memcached_append_by_key(memcached_st *ptr, const char
*group_key, size_t group_key_length, const char *key, size_t key_length,
const char *value, size_t value_length, time_t expiration, uint32_t
flags)

🎀 Parameters

here's every single one, no skips, we don't do that here 💅

• ptr -- pointer to an initialized memcached_st struct
• group_key -- key namespace
• group_key_length -- length of the key namespace without any terminating zero
• key -- the key
• key_length -- length of the key without any terminating zero
• value -- the value to append/prepend
• value_length -- the length of the value without any terminating zero
• expiration -- expiration as a unix timestamp or as relative expiration time in seconds
• flags -- 16 bit flags

⭐ Returns

memcached_return_t indicating success

---

👑 DESCRIPTION 👑

okay so memcached_prepend() and memcached_append() are the ones you call when you wanna modify information on a server. every single method takes a key and a key_length to store the object, and yes you need both, no skipping.

real talk about keys: they're currently limited to 250 characters when you're using either a version of memcached that's 1.4 or below, or when you're using the text protocol. so watch that.

you must supply both a value and a length — no vibes-only requests. optionally you can set an expiration time for the object, and a 16 bit value (it's meant to be used as a bitmap). flags is a 4 byte space that gets stored along the main value. a lot of sub libraries make use of this field, so in most cases users should avoid making use of it. like, mind your business on that one 🙈

now the actual behavior:

• memcached_prepend() places a segment of data before the last piece of data stored. Currently expiration and key are not used in the server.
• memcached_append() places a segment of data at the end of the last piece of data stored. Currently expiration and key are not used in the server.

and then there's the by-key girlies:

• memcached_prepend_by_key() and memcached_append_by_key() behave in a similar manner as the non key methods. the difference is that they use their group_key parameter to map objects to particular servers. that's it, that's the whole plot twist ✨

if you're looking for performance, memcached_set() with non-blocking IO is the fastest way to store data on the server. periodt.

🫶 the UDP situation (read this, bestie)

all of the above functions are tested with the MEMCACHED_BEHAVIOR_USE_UDP behavior enabled. however, when using these operations with this behavior on, there are limits to the size of the payload being sent to the server. 😭

the reason for these limits is that the Memcached Server does not allow multi-datagram requests and the current server implementation sets a datagram size to 1400 bytes. due to protocol overhead, the actual limit of the user supplied data is less than 1400 bytes and depends on the protocol in use as, well as the operation being executed.

• when running with the binary protocol, MEMCACHED_BEHAVIOR_BINARY_PROTOCOL, the size of the key, value, flags and expiry combined may not exceed 1368 bytes.
• when running with the ASCII protocol, the exact limit fluctuates depending on which function is being executed and whether the function is a cas operation or not. for non-cas ASCII set operations, there are at least 1335 bytes available to split among the key, key_prefix, and value; for cas ASCII operations there are at least 1318 bytes available to split among the key, key_prefix and value.

if the total size of the command, including overhead, exceeds 1400 bytes, a MEMCACHED_WRITE_FAILURE will be returned. that's the vibe check failing, and not in a cute way 💀

---

🌈 RETURN VALUE 🌈

all methods return a value of type memcached_return_t. on success the value will be MEMCACHED_SUCCESS. slay.

use memcached_strerror() to translate this value to a printable string. she'll tell you what's wrong, i promise 🎀

---

🧚 SEE ALSO 🧚

memcached(1) libmemcached(3) memcached_strerror(3) memcached_set(3) ‐ memcached_add(3) memcached_cas(3) memcached_replace(3)

---

and that's the whole page, bestie, you ate it 💅 this was libmemcached-awesome version 1.1, dated Jul 24, 2025, and MEMCACHED_APPEND_BY_KEY(3) said goodnight 🌙💜