Implement from_dict

[rakshith91]

No description provided.

[rakshith91]

/azp run python - eventgrid - tests

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[yunhaoling]

dumb question: what does the content look like, utf-8 base64 string?
also probably worth a better method name _decode_base64_string?

[rakshith91]

"data_base64":'Y2xvdWRldmVudA==',

[rakshith91]

so we decided not to expose data_base64 to users at all
see #16661

[rakshith91]

/azp run python - eventgrid - tests

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[rakshith91]

/azp run python - eventgrid - tests

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[yunhaoling]

I think it would be helpful if we could add description on the key-value items we accepts -- but it's a doc stuff

[rakshith91]

hmm, the payload normally comes directly from a storage queue - i can put a link to the relevant spec

[swathipil]

If not all the key-value pairs, at least mentioning that data_base64 will always be decoded and set as the value for the data field would be helpful. In general, maybe mentioning that from_dict will never result in the data_base64 field being set in the resulting CloudEvent object (if I'm getting that right).

[yunhaoling]

same comment as above regarding to the description of the dict accepted key-value items.

[yunhaoling]

as I mentioned in the from_dict, the dictionary item is data_base64 while we actually set it to the data which I think kinda breaks consistency from the experience of using the client constructor.

[yunhaoling]

In my understanding, to use the from_dict for CloudEvent, users should be doing this:

dict = {
    data_base64 = b'<base64 bytes>'
}

# or

dict = {
    data = data
}

which means internally we do:

data=event.pop("data", None)
data_base64=event.pop("data_base64", None),

is setting input data_base64 to the data argument by design?

[swathipil]

I think it is by design, and mirrors this. Similar to sending data that is of bytes type (sent as data_base64 in the outgoing request), when from_dict is used to deserialize, it sets data_base64 back to data.

[yunhaoling]

I'm thinking of the following two creation case which makes me feel the inconsistency, from intuition I would expect two cases to return the "same" CloudEvent :

event_created_from_class = CloudEvent(data_base64=b'bytes_data')
event_created_from_class.data is None
event_created_from_class.data_base64 is not None

event_created_from_dict = CloudEvent.from_dict({'data_base64':b'bytes_data'})
event_created_from_dict.data is not None
event_created_from_dict.data_base64 is None

apart from that, I notice that from_dict could take both data and data_base64, and if both are set data_base64 gets ignored:

# I think this should be an invalid input?
event_created_from_dict = CloudEvent.from_dict({'data': 'somedata', 'data_base64':b'bytes_data'})

[yunhaoling]

(I could also be wrong, might be missing some context here, just thinking out loud)

[swathipil]

That two ways that data_base64 can be deserialized is a little confusing since, no matter what, only data will end up being set. Maybe clarifying this in the docstring of from_dict would be useful?

[yunhaoling]

we could also do a cross-language check

[rakshith91]

update: we decided not to expose data_base64
#16661

[rakshith91]

Closing in favor of #16661