[Event Hubs Client] Skeleton API Track Two Preview 1 #6414
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
sdk/servicebus/Microsoft.Azure.ServiceBus/tests/QueueSessionTests.cs
Outdated
Show resolved
Hide resolved
AlexGhiondea
approved these changes
May 24, 2019
Initial skeleton for project structure and minimal assets.
The package references were preserved from the track one implementation
in order to allow for the same types to be used in the API surface where
applicable. These will be tuned as the prototype is built and the API
surface becomes more concrete.
Incorporation of feedback from the initial architecture board review.
General
- Replaced "Information" with "Properties" for metadata operations and types.
- Renamed retry policies to avoid confusion with Azure.Core types, prefixing with `EventHubs` and removing the `Policy` suffix.
- Renamed `EventPosition.EndOfStream` to `EventPosition.NewEventsOnly`
- Removed `EventBatch`, used to create a single batch of limited size; to be revisited post-June Preview.
Event Hub Client
- Renamed `GetEventSender` to `GetSender`
Event Sender
- Renamed optional timeout to `Timeout` for clarity.
- Removed the ability to send a single event, per advice from the Event Hubs product team.
- Restructured `SendAsync` to send all events grouped into a batch, per advice from the Event Hubs product team.
- Restructured batch options to allow control over the batching strategy applied to the sets of events.
Event Receiver
- Moved the `EventPosition` into the receiver options and made `NewEventsOnly` as the default
- Access to the Partition Properties.
Incorporation of feedback from the second and third architecture board reviews.
General
- Removed the concept of `ServiceVersion`, as the Event Hubs service team indicated that
they will not be supporting multiple versions and will guarantee strong backwards compatibility.
- Revised the names of (internal) properties on EventData that correspond to the event's position in
the stream, used by receivers for updating checkpoint information when they are populated. The
nomenclature inhereited from the track one implementation was unclear as to whether these properties
were relative to the event or to the partition where the event was located.
Event Hub Client
- Added documentation to assist in using the expected connection string from the portal.
- Added a `GetPartitionIds` shortcut method.
Event Receiver
- Removed the concept of `IsExclusiveReceiver` from the receiver and options; the priority will
be used as a determination of whether or not a receiver is intended to be exclusive.
- Revised the receiver checkpoint properties to have more clear semantics that indicate
"this is the last event that the receiver has read" and not the current state of the partition.
Refactoring sending of events to move specifying a partition to the creation of a sender, as it was mistakenly believed that a partition could be selected at send; this was the batch label (aka partition key) and not the identifier. Senders can now be created specific to a partition or non-specific, the latter of which will allow the Event Hubs service to assume responsibility for routing of events to a partition - the desired majority use case.
Corrected implementation of event properties with respect to positional data for checkpoints; there was a misunderstanding with respect to the information available on an event by default and that bound to the "UpdateRuntimeInformation" flag from track one.
|
Stub implementations used for prototyping and obtaining a "feel" for the API surface have been removed and replaced with |
- Trimming git metadata dangling file - Removing prototype stub implementations in favor of `NotImplementedException` throws.
52e516d to
86c1ff8
Compare
conniey
reviewed
May 27, 2019
| [EditorBrowsable(EditorBrowsableState.Never)] | ||
| public override string ToString() => base.ToString(); | ||
| } | ||
| } |
There was a problem hiding this comment.
Not sure if this is enforced in this repository, but new-line is missing from this file. 🤔
conniey
reviewed
May 28, 2019
| @@ -52,6 +52,7 @@ known_content_issues: | |||
| - ['sdk/keyvault/Microsoft.Azure.KeyVault/README.md','#5499'] | |||
| - ['sdk/servicebus/Microsoft.Azure.ServiceBus/README.md','#5499'] | |||
| - ['sdk/eventhub/Microsoft.Azure.EventHubs/README.md','#5499'] | |||
| - ['sdk/eventhub/Azure.Messaging.EventHubs/README.md','#5499'] | |||
There was a problem hiding this comment.
nit, should this be eventhubs rather than eventhub?
There was a problem hiding this comment.
Yes, it should, but the path had to match the repository for the REST specs, unfortunately.
conniey
reviewed
May 28, 2019
| /// <summary>The sequence number assigned to a message.</summary> | ||
| public const string SequenceNumber = "x-opt-sequence-number"; | ||
|
|
||
| /// <summary>The offset of a message within a fiven partition.</summary> |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
The goal of these changes to establish a basic skeleton for the API surface of the first preview for the track two API. The API surface represented herein has been reviewed by the architecture board and efforts have been made to align with the design of the other platforms.
Goals
Establish a basic skeleton with the API surface defined and fully documented via language doc comments.
Serve as the basis for implementation of the first preview for the Event Hubs track two client, offering the repository structure, metadata, and solution/project files.
Non-Goals
Providing the implementation or working features; the code is compilable, but contains only the most minimal stub implementation.
Containing a full set of supporting assets, such as README, samples, and ARM templates; these will happen as part of future efforts.
Enabling test parallelism; this will be a stretch goal in the second phase of these efforts.
Details
Last Upstream Rebase
Friday, May 24, 2019 3:42pm (EDT)
Related and Follow-Up Issues