-
Notifications
You must be signed in to change notification settings - Fork 0
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
feat: idsse-897: minor Publisher refactor #88
Conversation
@Geary-Layne this is 1 of 2 PRs that just moves the publishing logic from Publisher out into a reusable function. My second PR will have an |
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.
Looks good. I would like the 'private' functions to be moved to the bottom of the module, to fallow the convention of having the most relevant code for future users at the top.
@@ -23,6 +24,7 @@ | |||
|
|||
from pika import BasicProperties, ConnectionParameters, PlainCredentials | |||
from pika.adapters import BlockingConnection | |||
from pika.adapters.blocking_connection import BlockingChannel |
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.
Should we be importing (and using) both BlockingChannel and Channel from pika?
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.
If we wanted to cover our bases with type hinting, yes, technically all of the functions in rabbitmq_utils that take BlockingChannel
args should also work with a generic Channel
.
We only use BlockingConnections in rabbitmq_utils though, so all the channels created in this module with connection.channel()
will be specifically BlockingChannels.
if isinstance(rmq_params_and_callbacks, list): | ||
self._rmq_params_and_callbacks = rmq_params_and_callbacks |
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.
Did you drop the 'self.' because there is no need to store after initializing the instants, or is there another reason for the change?
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.
Yep, I just realized this wasn't used anywhere else in the class besides __init__
.
I found a bug that I thought I'd fix in your PR. Setting prefetch_count must be done before calling basic_consume.
Should the classes (Consumer and Producer) be at the top, then public functions, then private functions? As it stands it's organized as
|
I would definitely have private at the bottom, and have the most relevant to the module at the top. For rabbitmq_utils I think the classes are the most important. I'd have the helper classes first, then Consumer/Publisher/Rpc, then public threadsafe_, and last the private. I believe after RPC is added we won't need subscribe_to_queue and more, but maybe something will still need it. |
Update rabbitmq_utils.py
Ok, I followed your suggested order now.
|
* add protections for Publisher/Consumer using default exch or queue * setting prefetch_count must be done before calling basic_consume * re-order rabbitmq_utils classes and functions --------- Co-authored-by: Geary Layne <[email protected]>
Linear Issue
IDSSE-897
Changes
Shorter interim PR so the soon-to-exist
rabbitmq_utils.Rpc
class can reuse as much Publisher logic as possible.num_message_handlers
to2
.2
in actual usages of the Consumer class, because the caller doesn't usually care or know any better.Explanation
N/A