Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Message Properties: 'type' property #201

Open
notmeta opened this issue May 14, 2019 · 7 comments
Open

Message Properties: 'type' property #201

notmeta opened this issue May 14, 2019 · 7 comments

Comments

@notmeta
Copy link
Contributor

notmeta commented May 14, 2019

Since the new release aioamqp uses pamqp to encode/decode frames.

This also includes properties, but a subtle difference in naming for the 'type' property caused problems when I upgraded to the latest version.

aioamqp uses 'type', whereas pamqp uses 'message_type'.

This is not immediately obvious as the current aioamqp docs still specify 'type', see https://github.com/Polyconseil/aioamqp/blob/master/docs/api.rst#consuming-messages

Example:

# aioamqp 0.12.0
await conn.channel.publish(msg.payload,
                                               exchange_name=exchange_name,
                                               routing_key=routing_key,
                                               properties={'type': ...}  # fine
                                               )

# aioamqp 0.13.0
# returns UNEXPECTED_FRAME - expected content header for class 60, got non content header frame instead
await conn.channel.publish(msg.payload,
                                               exchange_name=exchange_name,
                                               routing_key=routing_key,
                                               properties={'type': ...}  # invalid
                                               )

# aioamqp 0.13.0
await conn.channel.publish(msg.payload,
                                               exchange_name=exchange_name,
                                               routing_key=routing_key,
                                               properties={'message_type': ...}  # fine
                                               )

I suggest one or more of the following changes:

  • Update the docs to make it obvious you need to use {'message_type': ... }
  • Update the actual property name to message_type
  • Provide a method to convert aioamqp.Properties into a dict which then converts type into message_type to be suitable for publishing (this is something I do in my code manually as there is no way to dynamically get all property keys and turn them into a dict)
    • Give aioamqp.Properties a .__dict__ method
  • Provide a channel.publish method which takes aioamqp.Properties as an argument instead of dict
@dzen
Copy link
Contributor

dzen commented May 18, 2019

Hello @notmeta.

Thanks for all your viable suggestions.
Imho there is two things:

First, we should rename type with message_type which will help us remove the disabled pylint and fix the issue quickly.

In a second hand, we should probably use the aioamqp.Properties to be used in channel.publish instead for a cleaner and self describing API, not an obscure dict argument.

What do you think ?

@notmeta
Copy link
Contributor Author

notmeta commented May 19, 2019

@dzen

Both sound good to me!

@dzen
Copy link
Contributor

dzen commented May 20, 2019

@notmeta I may have the time to propose the first part.

@notmeta
Copy link
Contributor Author

notmeta commented May 20, 2019

@dzen I may find some time to work on the second bit, if you're unable to.

Also I had a thought: since this is going to be a breaking change, how should the version upgrade go?
Are you guys wanting to follow semantic versioning, or should it just be implied that as this is pre-1.0.0 that breaking changes may happen at any time?

@dzen
Copy link
Contributor

dzen commented May 20, 2019

I think since we do not released a 1.x version, we may change the API. I think we did it already.

@dzen
Copy link
Contributor

dzen commented May 24, 2019

@notmeta : do you want a 0.13.x release ?

@notmeta
Copy link
Contributor Author

notmeta commented May 28, 2019

@dzen no rush on my end (as I've already fixed it in my codebase) but I'm sure others might encounter issues if they use that property.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants