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
MsgRequest
is used to set thef_lockout_key
member variable andf_lockout_key_is_valid
. This avoids the need to bind theuuid_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 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_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 amsg_request
object 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_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 ofMsgRequest
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 anyuuid_t
object within the C++ binding code.