-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Allow publishers to specify a different subject for "Nats-Expected-Last-Subject-Sequence" #5280
Comments
This change adds a new header "Nats-Expected-Last-Subject-Sequence-Subject" when when paired with "Nats-Expected-Last-Subject-Sequence" allows publishers to customize the subject used when the server enforces "Nats-Expected-Last-Subject-Sequence". Publishers can specify a alternative subject to be used that includes wildcards. Resolves nats-io#5280 Signed-off-by: Caleb Champlin <caleb.champlin@gmail.com>
Looping in some people who know more about event sourcing than me @bruth @codegangsta |
If we can get this change accepted or have some discussion around it we'd also like to propose an additional set of headers: JSExpectedLastSubjHeader = "Nats-Expected-Last-Subject-Header"
JSExpectedLastSubjHeaderSubj = "Nats-Expected-Last-Subject-Header-Subject" That would allow publishers to specify an expected header and value on the last message for a message subject or an overriding subject. For example In this case nats server would grab the last message for the subject on the stream, extract the "Aggregate-Version" header from that message and compare it against Flexible on the exact details, pattern, and names of things here, but hoping the idea gets some traction. |
Mirrors are bit for bit copies, so sequence and timestamp stay the same. For sources they change, but we preserve the originals in headers. |
@cchamplin This is a great addition and straightforward PR. I will want to play with this a bit to see how much this could be abused (subject length/number of tokens), but I am very supportive of this. Solves a very concrete problem for ES. |
This change adds a new header "Nats-Expected-Last-Subject-Sequence-Subject" when when paired with "Nats-Expected-Last-Subject-Sequence" allows publishers to customize the subject used when the server enforces "Nats-Expected-Last-Subject-Sequence". Publishers can specify a alternative subject to be used that includes wildcards. Resolves nats-io#5280 Signed-off-by: Caleb Champlin <caleb.champlin@gmail.com>
Yeah I really like this addition. like @bruth I'd like the opportunity to play with it this week |
…5281) This change adds a new header "Nats-Expected-Last-Subject-Sequence-Subject" when when paired with "Nats-Expected-Last-Subject-Sequence" allows publishers to customize the subject used when the server enforces "Nats-Expected-Last-Subject-Sequence". Publishers can specify a alternative subject to be used that includes wildcards. Resolves #5280 Signed-off-by: Caleb Champlin <caleb.champlin@gmail.com>
This change adds a new header "Nats-Expected-Last-Subject-Sequence-Subject" when when paired with "Nats-Expected-Last-Subject-Sequence" allows publishers to customize the subject used when the server enforces "Nats-Expected-Last-Subject-Sequence". Publishers can specify a alternative subject to be used that includes wildcards. Resolves #5280 Signed-off-by: Caleb Champlin <caleb.champlin@gmail.com>
Proposed change
I'd like to request a change to allow publishers to provide a specific subject for use when nats-server enforced "Nats-Expected-Last-Subject-Sequence". Adding an additional header field that allows publishers to optionally change the subject used for "Nats-Expected-Last-Subject-Sequence" from the subject of the message being published to to a subject provided in the header.
The proposal is for a "Nats-Expected-Last-Subject-Sequence-Subject" header that when set with a string value becomes the subject used during enforcement of the last sequence. The header does not necessarily need to be that string exactly, the functionality is the actual proposal.
Use case
The specific use case I am trying to solve here is to allow publishing to complex and dynamic subjects while still enabling optimistic concurrency control.
For example in an event sourcing application an aggregate might be defined against the subject:
Today we can use "Nats-Expected-Last-Subject-Sequence" to ensure that when we publish to
orders.2
we are publishing against the known last sequence for messages on theorders.2
subject.However, it is often desirable to have more complex subject patterns. For example image a pattern that looks like this:
Today we cannot use "Nats-Expected-Last-Subject-Sequence" with this pattern and still have OCC for the aggregate
orders.2
when publishing. If a publisher attempts to set the expected sequence and then publish toorder.2.rejected.private
the sequence for that subject is likely 0 as opposed to sequence for the last event published toorder.2.>
By allowing publishers to override and customize the subject used in the expect last subject sequence check OCC can be enforced for the aggregate itself versus the subject being published to. For example by setting the proposed "Nats-Expected-Last-Subject-Sequence-Subject" to "order.2.>"
Relevant Slack Conversations:
Contribution
Possibly
The text was updated successfully, but these errors were encountered: