Feature/additional space and message type fields #153
Conversation
seba-aln
force-pushed
the
feature/additional-space-and-message-type-fields
branch
from
ce4d004 to
1109fad
Compare
seba-aln
force-pushed
the
feature/additional-space-and-message-type-fields
branch
from
64eb34a to
6c2e89a
Compare
Fix tests for native sync publish Fix leaky serializer
seba-aln
force-pushed
the
feature/additional-space-and-message-type-fields
branch
from
6c2e89a to
00e1b16
Compare
cleanup + add acceptance test action
seba-aln
force-pushed
the
feature/additional-space-and-message-type-fields
branch
from
00e1b16 to
4b4776e
Compare
pubnub/endpoints/fetch_messages.py
Outdated
| params = {'max': int(self._count)} | ||
| params = { | ||
| 'max': int(self._count), | ||
| 'include_type': 'true' if self._include_message_type else 'false', |
There was a problem hiding this comment.
'include_type': str(self._include_message_type).lower()
| params = { | ||
| 'max': int(self._count), | ||
| 'include_type': 'true' if self._include_message_type else 'false', | ||
| 'include_message_type': 'true' if self._include_message_type else 'false', |
There was a problem hiding this comment.
'include_type': str(self._include_message_type).lower()
| if self._include_message_type is not None: | ||
| params['include_message_type'] = "true" if self._include_message_type else "false" | ||
| if self._include_space_id is not None: | ||
| params['include_space_id'] = "true" if self._include_space_id else "false" |
There was a problem hiding this comment.
params['include_space_id'] = str(self. _include_space_id).lower()
There was a problem hiding this comment.
space_id can be null and in this case the parameter should not be added, that's why there's if statement
| @@ -0,0 +1,27 @@ | |||
| class PNMessageType: | |||
There was a problem hiding this comment.
This class look like a good example of enum class:
https://docs.python.org/3/library/enum.html
There was a problem hiding this comment.
Well Enum is a closed set of values - this is more like a wrapper around two independent message types:
- One is user-defined and can be any string (with some constrains on server side)
- Second is our own internal message type, which is numeric
In both cases we want to deliver to client a string. If he didn't defined his own message type, we return "mapped" version of our internal message type.
Either way we also allow access to "raw" values usingPNMessageType.message_typeandPNMessageType.pn_message_typeproperties. And i guess enum doesn't have such possibilities
There was a problem hiding this comment.
Every time we need to explain this I'm wondering if that's actually a good decision. Especially when you put it like that:
wrapper around two independent message types.
seba-aln
force-pushed
the
feature/additional-space-and-message-type-fields
branch
from
52774ec to
da677ba
Compare
| @@ -0,0 +1,27 @@ | |||
| class PNMessageType: | |||
There was a problem hiding this comment.
Every time we need to explain this I'm wondering if that's actually a good decision. Especially when you put it like that:
wrapper around two independent message types.
seba-aln
force-pushed
the
feature/additional-space-and-message-type-fields
branch
from
d443f63 to
c35ba87
Compare
No description provided.