[ServiceBus] Update migration guide #15915
Conversation
| | `ServiceBusClient.from_connection_string()` | `ServiceBusClient.from_connection_string()` | [using credential](https://github.com/Azure/azure-sdk-for-python/tree/master/sdk/servicebus/azure-servicebus/samples/sync_samples/authenticate_client_connstr.py ) | | ||
| | `QueueClient.from_connection_string()` | `ServiceBusClient.from_connection_string().get_queue_<sender/receiver>()` | [client initialization](https://github.com/Azure/azure-sdk-for-python/tree/master/sdk/servicebus/azure-servicebus/samples/sync_samples/send_queue.py ) | | ||
| | `QueueClient.from_connection_string(idle_timeout=None)` | `ServiceBusClient.from_connection_string.get_queue_receiver(max_wait_time=None)` | [providing a timeout](https://github.com/Azure/azure-sdk-for-python/tree/master/sdk/servicebus/azure-servicebus/samples/sync_samples/session_pool_receive.py) | | ||
| In V0.50: |
There was a problem hiding this comment.
What is the reason the table format is changed? Also, I think there's a great value in providing the relevant sample in place
There was a problem hiding this comment.
I totally agree with you that table has the advantage for comparison.
but what I found is that table might be good for comparison of short/brief code snippets, but too crowded for large content.
for example this one:
I think the readability decreases as we want to show more contents in a table. one approach might be we further compress the code snippets, but flattening it out also help users who just want to copy and past the code.
actually, I think Message properties migration guide segment is a perfect case to apply table.
we could discuss further which sections are suitable for table, and see how others are doing.
Co-authored-by: Rakshith Bhyravabhotla <rakshith.bhyravabhotla@gmail.com> Co-authored-by: swathipil <76007337+swathipil@users.noreply.github.com>
| subscription_dead_letter_receiver = subscription_client.get_deadletter_receiver() | ||
| ``` | ||
|
|
||
| In V7: | ||
| ```Python | ||
| with ServiceBusClient.from_connection_string(connstr) as client: |
There was a problem hiding this comment.
Any reason to use the with construct in the v7 code snippet but not in v0.50?
There was a problem hiding this comment.
it's because v5 ServiceBusClient doesn't support the with context manager.
but I tend to keep the usage of with for v7 for consistency with other snippets.
| # receiver.abandon_message(received_message) | ||
| # receiver.defer_message(received_message) | ||
| # receiver.dead_letter_message(received_message) | ||
| ``` | ||
|
|
||
| ### Renewing lock on the received message |
There was a problem hiding this comment.
Can we combine the auto lock renewal section in here? Since both topics are about lock renewals it would make sense to have a single section called Lock renewal
There was a problem hiding this comment.
good suggestion, I tried to combine them into one, let me know how it looks to you.
| receiver.renew_message_lock(received_message) | ||
| ``` | ||
|
|
||
| ### Scheduling messages and cancelling scheduled messages |
There was a problem hiding this comment.
There is not much in this section other than renames. In which case I would either recommend not calling them out at all or having a separate section called "Renames" (or something nicer :) ) and put these there. Having a dedicated section is helpful if the method has moved or has changed in what it accepts as input or changes what it returns as output.
Other sections that fall under the same category are the ones for utc time and for receiving messages
There was a problem hiding this comment.
There is a change in the schedule/cancel schedule api that in v0.50 the method takes argument list while in v7 it takes list so I'd like to keep it.
I have removed the utc time section; as for the receiving messages sections since it's a champion scenario I tend to keep it as it is.
…/yunhaoling/azure-sdk-for-python into yuling/sb/migration-guide-update
| and [Async API](https://azuresdkdocs.blob.core.windows.net/$web/python/azure-servicebus/latest/azure.servicebus.aio.html#azure.servicebus.aio.ServiceBusSender) | ||
| * `ServiceBusReceiver` for receiving messages. [Sync API](https://azuresdkdocs.blob.core.windows.net/$web/python/azure-servicebus/latest/azure.servicebus.html#azure.servicebus.ServiceBusReceiver) | ||
| and [Async API](https://azuresdkdocs.blob.core.windows.net/$web/python/azure-servicebus/latest/azure.servicebus.aio.html#azure.servicebus.aio.ServiceBusReceiver) | ||
| In V0.50: |
There was a problem hiding this comment.
Not blocking this PR, but thoughts for a future PR
We want to show 3 different things here
- That constructing the client using connection string has not changed
- Constructing client using SAS key and name is an upcoming feature
- Using AAD is a brand new feature
Consider treating these separately. For example:
Constructing the client using the connection string is same in both versions.
servicebus_client = ServiceBusClient.from_connection_string(conn_str)
Additionally, you can now use Azure Active Directory for authentication via the
azure-identitylibrary
show code for AAD here
The option to construct the client using SAS key name and value is not available in the new version, but will be added in the near future.
There was a problem hiding this comment.
I love the way you organize the concepts, I have copied your words and tweaked a bit.
* update migration guide * Apply suggestions from code review Co-authored-by: Rakshith Bhyravabhotla <rakshith.bhyravabhotla@gmail.com> Co-authored-by: swathipil <76007337+swathipil@users.noreply.github.com> * addressing comments * tweak table of contents * update according to comments Co-authored-by: Rakshith Bhyravabhotla <rakshith.bhyravabhotla@gmail.com> Co-authored-by: swathipil <76007337+swathipil@users.noreply.github.com>
[Hub Generated] Review request for Microsoft.PowerBIdedicated to add version stable/2017-10-01 (Azure#15915) * Update missing properties in PowerBIDedicated objects 2017-10-01 * Move PowerBIDedicated properties to new definitions * Realign error response to recommended schema. 202 response not necessary in older api-version.
addressing: #15106 and #14202