Hi everybody,

I'm experimenting with the (low level) DAOS Key Value API, i.e. daos_kv_get and friends. For the get function, I observed that passing an non-existent key returns both 0, indicating success, as well as an "actual size of the value" of again 0.

However, it is also valid to put a key with a zero length value into the KV store. That key is subsequently found when enumerating the names inside the object (daos_kv_list).

Is this behavior of the get operation, i.e. returning success and an empty (value), intended? If so, how can I check if a queried key really existed other than by enumerating the (whole) object?

Regards, Steffen

Hi Steffen,

We have recently added conditional operations to the DAOS object and KV api to allow for such conditional operations:
DAOS_COND_KEY_INSERT/UPDATE/FETCH/PUNCH (for the daos_kv_* API)
Which would give you what you need.

However for the KV API, I actually see an issue where these flags are not properly set.
I will push a patch to fix this soon and let you know.

Thanks,
Mohamad

On 8/24/20, 7:59 AM, "daos@daos.groups.io on behalf of Steffen Christgau" <daos@daos.groups.io on behalf of christgau@...> wrote:

Hi everybody,

I'm experimenting with the (low level) DAOS Key Value API, i.e.
daos_kv_get and friends. For the get function, I observed that passing
an non-existent key returns both 0, indicating success, as well as an
"actual size of the value" of again 0.

However, it is also valid to put a key with a zero length value into the
KV store. That key is subsequently found when enumerating the names
inside the object (daos_kv_list).

Is this behavior of the get operation, i.e. returning success and an
empty (value), intended? If so, how can I check if a queried key really
existed other than by enumerating the (whole) object?

Regards, Steffen

On 8/25/20 3:19 PM, Chaarawi, Mohamad wrote:

We have recently added conditional operations to the DAOS object and KV api to allow for such conditional operations:
DAOS_COND_KEY_INSERT/UPDATE/FETCH/PUNCH (for the daos_kv_* API)
Which would give you what you need.

Thanks for pointing that out, Mohamad.

However for the KV API, I actually see an issue where these flags are not properly set.
I will push a patch to fix this soon and let you know.

Great. Looking forward for a notification.

Just to be sure: Given that the API would work correctly, these conditional operations are passed with the flags parameter which are marked as "currently ignored"?!

Regards, Steffen

Hi Steffen,

Sorry for not sending this earlier, but I have landed some changes to the KV API to:
1) enable using & checking the conditional flags in the put/get/punch operations
2) Add separate open / close operations for the KV object instead of the base open close. Note that this requires a change to your existing code to use the kv open / close. This is really to align with like the array api which has it's own API for open close and require we set some feature flags on the oid for KV object.

Please see the kv test or the simple object program for some simple example usage:
https://github.com/daos-stack/daos/blob/master/src/tests/suite/daos_kv.c
https://github.com/daos-stack/daos/blob/master/src/tests/simple_obj.c

All that should be available in latest master or the 1.1.1 tag.

Thanks,
Mohamad

On 8/25/20, 9:17 AM, "daos@daos.groups.io on behalf of Steffen Christgau" <daos@daos.groups.io on behalf of christgau@...> wrote:

On 8/25/20 3:19 PM, Chaarawi, Mohamad wrote:
> We have recently added conditional operations to the DAOS object and KV api to allow for such conditional operations:
> DAOS_COND_KEY_INSERT/UPDATE/FETCH/PUNCH (for the daos_kv_* API)
> Which would give you what you need.

Thanks for pointing that out, Mohamad.

> However for the KV API, I actually see an issue where these flags are not properly set.
> I will push a patch to fix this soon and let you know.

Great. Looking forward for a notification.

Just to be sure: Given that the API would work correctly, these
conditional operations are passed with the flags parameter which are
marked as "currently ignored"?!

Regards, Steffen