Docs updated.
On Sat, 28 Apr 2007, Alex Stapleton wrote: > > 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 > >> > >> > >> > >
