Currently a member function of MsgRequest is used to set the f_lockout_key member variable and f_lockout_key_is_valid. This avoids the need to bind the uuid_t data type into python (and avoids any question of interoperability with the existing python UUID type). However, this is not done properly as it has different behavior than the C++ interface for dealing with f_lockout_key, and it doesn't respect the intended meaning of f_lockout_key_is_valid.
Starting with the last point, f_lockout_key_is_valid is intended to be used for a message that comes in from the AMQP broker. The lockout_key field is stored as a string, so in translation to a msg_request object the UUID of the lockout_key has to be parsed. If that parsing fails, then a nil UUID (all zeroes) is used for f_lockout_key. But that introduces the potential confusion with a situation where the sender of a request actually included a nil UUID for that field. So instead we introduced the f_lockout_key_is_valid field to identify the situation in which the key-as-string was not valid.
Requested behavior
The set behavior of the lockout_key property of MsgRequest should be to attempt the parsing of the provided key, and if it fails, to raise an exception. That will best match the behavior of the C++ code, while still encapsulating the use of any uuid_t object within the C++ binding code.
Currently a member function of
MsgRequestis used to set thef_lockout_keymember variable andf_lockout_key_is_valid. This avoids the need to bind theuuid_tdata type into python (and avoids any question of interoperability with the existing python UUID type). However, this is not done properly as it has different behavior than the C++ interface for dealing withf_lockout_key, and it doesn't respect the intended meaning off_lockout_key_is_valid.Starting with the last point,
f_lockout_key_is_validis intended to be used for a message that comes in from the AMQP broker. The lockout_key field is stored as a string, so in translation to amsg_requestobject the UUID of the lockout_key has to be parsed. If that parsing fails, then a nil UUID (all zeroes) is used forf_lockout_key. But that introduces the potential confusion with a situation where the sender of a request actually included a nil UUID for that field. So instead we introduced thef_lockout_key_is_validfield to identify the situation in which the key-as-string was not valid.Requested behavior
The set behavior of the
lockout_keyproperty ofMsgRequestshould be to attempt the parsing of the provided key, and if it fails, to raise an exception. That will best match the behavior of the C++ code, while still encapsulating the use of anyuuid_tobject within the C++ binding code.