Cloud Event Abstraction #13542
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -7,6 +7,7 @@ | |
| from msrest.serialization import UTC | ||
| import datetime as dt | ||
| import uuid | ||
| import base64 | ||
|
||
| import json | ||
| import six | ||
| from ._generated import models | ||
|
|
@@ -50,7 +51,7 @@ def _from_json(event, encode): | |
| return event | ||
|
|
||
|
|
||
| class CloudEvent(EventMixin): #pylint:disable=too-many-instance-attributes | ||
| """Properties of an event published to an Event Grid topic using the CloudEvent 1.0 Schema. | ||
|
|
||
| All required parameters must be populated in order to send to Azure. | ||
|
|
@@ -75,35 +76,67 @@ class CloudEvent(InternalCloudEvent, EventMixin): #pylint:disable=too-many-ins | |
| unique for each distinct event. | ||
| :type id: Optional[str] | ||
| """ | ||
| def __init__(self, source, type, **kwargs): | ||
| # type: (str, str, Any) -> None | ||
| self.source = source | ||
| self.type = type | ||
| self.specversion = kwargs.get("specversion", "1.0") | ||
| self.id = kwargs.get("id", str(uuid.uuid4())) | ||
| self.time = kwargs.get("time", dt.datetime.now(UTC()).isoformat()) | ||
| self.data = kwargs.get("data", None) | ||
| self.datacontenttype = kwargs.get("datacontenttype", None) | ||
| self.dataschema = kwargs.get("dataschema", None) | ||
| self.subject = kwargs.get("subject", None) | ||
| self._extensions = {} | ||
|
|
||
| spec_attr = [ | ||
| 'source', 'type', 'specversion', 'id', 'time', | ||
| 'data', 'datacontenttype', 'dataschema', 'subject'] | ||
| for attr in kwargs: | ||
| if attr == 'extensions': | ||
| self._extensions.update({k:v for k, v in kwargs.get('extensions').items()}) | ||
| elif attr not in spec_attr: | ||
|
||
| self._extensions.update({attr: kwargs.get(attr)}) | ||
|
|
||
| @classmethod | ||
| def _from_generated(cls, generated, **kwargs): | ||
| if generated.additional_properties: | ||
| extensions = {k:v for k, v in generated.additional_properties.items()} | ||
| kwargs.setdefault('extensions', extensions) | ||
| return cls( | ||
| id=generated.id, | ||
| source=generated.source, | ||
| type=generated.type, | ||
| specversion=generated.specversion, | ||
| data=generated.data or generated.data_base64, | ||
| time=generated.time, | ||
| dataschema=generated.dataschema, | ||
| datacontenttype=generated.datacontenttype, | ||
| subject=generated.subject, | ||
| **kwargs | ||
| ) | ||
|
|
||
| def _to_generated(self, **kwargs): | ||
| if isinstance(self.data, six.binary_type): | ||
| data_base64 = self.data | ||
| data = None | ||
| else: | ||
| data_base64 = None | ||
| data = self.data | ||
| return InternalCloudEvent( | ||
| id=self.id, | ||
| source=self.source, | ||
| type=self.type, | ||
| specversion=self.specversion, | ||
| data=data, | ||
| data_base64=data_base64, | ||
| time=self.time, | ||
| dataschema=self.dataschema, | ||
| datacontenttype=self.datacontenttype, | ||
| subject=self.subject, | ||
| additional_properties=self._extensions, | ||
| **kwargs | ||
|
Member
There was a problem hiding this comment. Extensions should be passed part of additional_properties In [3]: c=CloudEvent(id=42, source="source", type="type", specversion="1.0", additional_properties={"foo":True})
In [4]: c.serialize()
Out[4]:
{'foo': True,
'id': '42',
'source': 'source',
'type': 'type',
'specversion': '1.0'}
Member
There was a problem hiding this comment. Apologies if I misremembered our call the other day but did we reach a conclusion about not using kwargs for extensions? My fear being that we've just lost symmetry if someone **'s a serialized cloudevent back into itself.
Contributor
Author
There was a problem hiding this comment. i took the liberty to slightly change the behavior to this will serialize to In other words, extensions can be accepted as both kwargs and an explicit extensions dictionary Rationale is
I can disallow kwargs if there is a strong opinion against this
Member
There was a problem hiding this comment. The pitfall here is if someone has an additional property called additional_properties, we get "undefined behavior". I seem to recall a mention in the call that we weren't TOO worried about that/could document it/reserved keywords and all that, but it's the one thing that irks me. This may be a good target for getting some broader user input on, having them hit this pitfall and see if it's dig-out-able or understandable to their eyes.
Member
There was a problem hiding this comment.
:) What if you do I'm not against it and it has appeal, but right now I want to be sure we have the base minimal behavior, and improve from it first.
Contributor
Author
There was a problem hiding this comment. changed it to accepting only extensions - thank you both for the inputs
Member
There was a problem hiding this comment. Also @KieranBrantnerMagee , I'm catching up your comment, |
||
| ) | ||
|
|
||
|
|
||
| class EventGridEvent(InternalEventGridEvent, EventMixin): | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,38 @@ | ||
| interactions: | ||
| - request: | ||
| body: '[{"reason_code": 204, "extension": "extension", "id": "9da8e4ce-df2c-4480-b809-c7132fb3ee74", | ||
| "source": "http://samplesource.dev", "data": "cloudevent", "type": "Sample.Cloud.Event", | ||
| "time": "2020-09-03T21:37:15.165652Z", "specversion": "1.0"}]' | ||
| headers: | ||
| Accept: | ||
| - '*/*' | ||
| Accept-Encoding: | ||
| - gzip, deflate | ||
| Connection: | ||
| - keep-alive | ||
| Content-Length: | ||
| - '244' | ||
| Content-Type: | ||
| - application/cloudevents-batch+json; charset=utf-8 | ||
| User-Agent: | ||
| - azsdk-python-eventgridpublisherclient/unknown Python/3.7.3 (Windows-10-10.0.18362-SP0) | ||
| method: POST | ||
| uri: https://cloudeventgridtestegtopic.westus-1.eventgrid.azure.net/api/events?api-version=2018-01-01 | ||
| response: | ||
| body: | ||
| string: '' | ||
| headers: | ||
| api-supported-versions: | ||
| - '2018-01-01' | ||
| content-length: | ||
| - '0' | ||
| date: | ||
| - Thu, 03 Sep 2020 21:37:13 GMT | ||
| server: | ||
| - Microsoft-HTTPAPI/2.0 | ||
| strict-transport-security: | ||
| - max-age=31536000; includeSubDomains | ||
| status: | ||
| code: 200 | ||
| message: OK | ||
| version: 1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's a weird feeling for me that the caller has to know both about the CloudEvent and the InternalCloudEvent. Would it not offer better separation of concerns/isolation to have the InternalCloudEvent.deserialize within the _from_generated so the caller never sees anything but our "nice and pretty" object contract?