Refactor event streams to target members #171
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
kstich
requested changes
Sep 23, 2019
smithy-model/src/test/java/software/amazon/smithy/model/knowledge/EventStreamIndexTest.java
Outdated
Show resolved
Hide resolved
...est/resources/software/amazon/smithy/model/errorfiles/validators/event-stream-validator.json
Show resolved
Hide resolved
This commit removes the inputEventStream and outputEventStream traits and replaces them with the eventStream trait that targets members. This simplifies the model, validation, code generation, and I found that it makes it easier to model operations correctly. In fact, several typos were fixed in the documentation while making these changes due to the fact that the previous design required that the member name of an input/output shape is referenced from the operation. The major drawbacks of this approach are: 1) It's a breaking change. While this is a breaking change, no models are currently using the event stream feature in Smithy, and external tooling hasn't been published that consumes them either. 2) Structures that contain an event stream cannot be targeted by anything other than operation input or output. While it's awkward that event stream structures are essentially "poisoned" and can't be targeted by other members or used as errors, it does make event stream far easier to use with code generation since the structure itself does not need to be specialized when generating operation inputs and outputs. If we find ourselves needing to use this for other abstractions, something more reusable like a trait attribute could be introduced to automate this validation.
mtdowling
force-pushed
the
refactor-event-streams
branch
from
d541696 to
a47242a
Compare
kstich
approved these changes
Sep 24, 2019
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.
This commit removes the inputEventStream and outputEventStream traits
and replaces them with the eventStream trait that targets members. This
simplifies the model, validation, code generation, and I found that it
makes it easier to model operations correctly. In fact, several typos
were fixed in the documentation while making these changes due to the
fact that the previous design required that the member name of an
input/output shape is referenced from the operation.
The major drawbacks of this approach are:
It's a breaking change. While this is a breaking change, no models are
currently using the event stream feature in Smithy, and external tooling
hasn't been published that consumes them either.
Structures that contain an event stream cannot be targeted by anything
other than operation input or output. While it's awkward that event stream
structures are essentially "poisoned" and can't be targeted by other
members or used as errors, it does make event stream far easier to use
with code generation since the structure itself does not need to be
specialized when generating operation inputs and outputs. If we find
ourselves needing to use this for other abstractions, something more
reusable like a trait attribute could be introduced to automate this
validation.
Issue #, if available:
Description of changes:
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.