(2010/04/12 9:56), KaiGai Kohei wrote:
> (2010/04/10 15:52), Trond Norbye wrote:
>>
>> Sorry for being silent for a bit, but I was trying to think this through.
>> I've refactored the code now so that it should allow you to do what you want
>> (but in a slightly different way). Instead of providing functions to query
>> the individual parts of the item, the core calls a single function to fill
>> a structure with all the information it needs. This means that all of the
>> members of the old item structure is gone...
>>
>> I've got all tests passing and will push the change when I'm done reviewing
>> the change...
>>
>> Trond
>
> Thanks for your efforts. It seems to me the right direction.
>
> I understand an item object identified with a key has multiple properties
> from perspective of the model.
> The value is the most important property of the item. In addition, it already
> has cas value and expired time; these are also properties of items.
>
> It seems to me the new get_item_info() interface intends to contain various
> kind of properties more than bare threes (value, cas and expired time),
> because we can easily expand the number of 'struct iovec value[]' in the
> new item_info.
>
> If so, I think the allocate() interface should be also modified as follows:
>
> ENGINE_ERROR_CODE (*allocate)(ENGINE_HANDLE* handle,
> const void* cookie,
> item **item,
> const void* key,
> ! int nslots, /* # of nbytes[]
> array */
> ! const size_t nbytes[], /* # of properties */
> const int flags);
>
> It enables to suggest number of properties and length of them for each
> property slot.
> Maybe, we use three slots for value, cas and expired time.
> The caller knows what slot is reserved for what purpose.
>
> For example, if slot=0 is reserved for value, and slot=1 is reserved for
> exptime, we calls the allocate() method with nbytes[0]=(length of value)
> and nbytes[1]=sizeof(rel_time_t).
>
> If here is an intermediating engine module (such as selinux), it can increment
> the given nslot before calling the secondary engine, and the added slot will
> be available for the intermediating engine transparently.
>
> I'll try to implement a proof of concept patch.
BTW, the current get_item_info() interface needs to share the identical
structure format between memcached-core and engine-module.
It may need to increment API version when we add minor changes into the
item_info structure in the future.
It seems to me the following interfaces are more portable to get/set
a certain attribute of the item. I'd like to see your opinion.
typedef enum {
ITEM_ATTR_KEY = 0,
ITEM_ATTR_VALUE,
ITEM_ATTR_EXPIRE_TIME,
:
ITEM_ATTR_CAS,
ITEM_LEAST_ATTRS
} ENGINE_ATTRIBUTE;
=> Any item have ITEM_LEAST_ATTRS of attributes, so all the engine
module has to provide a capability to store these attributes.
If here is an intermediating module, it can inject its attribute
with a larger attribute number.
const void *get_item_attr(ENGINE_HANDLE *handle,
ENGINE_ATTRIBUTE attnum,
const item *item,
uint32_t *nbytes);
It returns the pointer to the attribute field and its length.
bool set_item_attr(ENGINE_HANDLE *handle,
ENGINE_ATTRIBUTE attnum,
const item *item,
const uint8_t *data,
uint32_t nbytes);
It sets the given data with nbytes length on the specified number of
attribute field. The given nbytes length has to be less or equal with
the pre-allocated length in allocate() method.
Currently, we still have item_set_cas() method in engine.
It seems to me above two methods enables to get/set any attributes
without caller knowing any engine specific data layout.
Thanks,
--
KaiGai Kohei <[email protected]>
--
To unsubscribe, reply using "remove me" as the subject.
