On 28 Apr 2007, at 17:36, Brad Fitzpatrick wrote:
Historically, at least, it was only 16 bits. It might only be 16 bits
currently on accident, and might be truncated back to 16 bits in the
future if we go on another struct item packing mission.
But yeah -- perhaps we should do a range check on it to prevent people
from getting bitten?
Does anybody remember when this changed from 16 bit to 32 bit, and if
there was a good reason?
It's actually rather useful for us, i'd much rather you kept it at 32-
bits, or offered it as an option to ./configure at least :)
We cache data both locally to each node using eaccelerator and also
across the cluster with memcached. Basically we need to keep the ttls
between memcached and the local caches in sync so we store the expiry
time of the key in the flags field on memcached and then recalculate
the expiry time on retrieval before it's added to eaccelerator.
OT: oh btw, has anyone else noticed that PHP doesn't have an unsigned
int data type? I hope they fix that before the epoch hits 2147483647...
On Sat, 28 Apr 2007, Alex Stapleton wrote:
- <flags> is an arbitrary 16-bit unsigned integer (written out in
decimal) that the server stores along with the data and sends back
when the item is retrieved. Clients may use this as a bit field to
store data-specific information; this field is opaque to the
server.
However looking at the source, and testing it out myself, this
appears to be a lie. unsigned 32-bit ints appear to be used to store
flags with no range checks which means it works just fine if you
store 32-bit values in there. afaict the high 16-bits aren't used for
anything internally either. Is this right? Is it safe to use values
65535 in the flags field of a key? Being able to stick a 32-bit
value in there certainly is rather handy with the rather unusual
configuration we are using :)
Alex Stapleton
[EMAIL PROTECTED]
T: 0207 0700 956
