Skip to content

Add some additional design points for ID #403

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.

Sign up for GitHub

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

Merged
duglin merged 2 commits into from
Jun 1, 2019
Merged

Add some additional design points for ID #403

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
c8e4506
Add some additional design points for ID
Mar 14, 2019
845a226
even's comment
May 31, 2019
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
31 changes: 31 additions & 0 deletions primer.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -147,6 +147,37 @@ Some form of communication between producers and consumers should be established
to ensure the event consumers know what possible values might be used. In
general, this is true for all CloudEvents attributes as well.

## CloudEvent Attributes

This section provides additional background and design points related to some
of the CloudEvent attributes.

### id

The `id` attribute is meant to be a value that is unique across all events
related to one event source (where each event source is uniquely identified by
its CloudEvents `source` attribute value). While the exact value used
is producer defined, receivers of CloudEvents from a single
event source can be assured that no two events will share the same `id`
value. The only exception to this is if some replay of the event is supported,
and in those cases, the `id` can then be used to detect this.

Since a single occurrence may result in the generation of more than one
event, in the cases where all of those events are from the same event source,
each CloudEvent constructed will have a unique
`id`. Take the example of the creation of a DB entry, this one occurrence
might generate a CloudEvent with a type of `create` and a CloudEvent with
a type of `write`. Each of those CloudEvents would have a unique `id`. If
there is the desire for some correlation between those two CloudEvents
to indicate they are both related to the same occurrence, then some additional
data within the CloudEvent would be used for that purpose.

In this respect, while the exact value chosen by the event producer might
be some random string, or a string that has some semantic meaning in some other
context, for the purposes of this CloudEvent attribute those meanings are not
relevant and therefore using `id` for some other purpose beyond uniqueness
checking is out of scope of the specification and not recommended.

## CloudEvent Attribute Extensions

In order to achieve the stated goals, the specification authors will attempt to
Expand Down