-
Notifications
You must be signed in to change notification settings - Fork 3
Clarify the order of changes in CDC #73
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
Conversation
* Node deletions | ||
* Relationship deletions | ||
|
||
Note that the order of changes in the output is **not guaranteed** to match exactly the order of changes occurring in the transaction. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd put this as leading sentence for the section (without Note that
), as the listed ordering is a further explanation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think of this as a clarification instead, since the section is about the order within the output rather than in the transaction, but I'm fine either way. I'm including the change.
|
||
Note that the order of changes in the output is **not guaranteed** to match exactly the order of changes occurring in the transaction. | ||
|
||
CDC tracks logical changes only; therefore, if two or more changes cancel each other (for example, a `DELETE` following a `CREATE` on the same node), none is included in the change stream. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
CDC tracks logical changes only; therefore, if two or more changes cancel each other (for example, a `DELETE` following a `CREATE` on the same node), none is included in the change stream. | |
CDC tracks logical changes only: if two or more changes cancel each other out (for example, a `DELETE` following a `CREATE` on the same node), none is included in the change stream. |
Also, is logical
the right term here? It may be and I just don't know it; otherwise, something like effective
could be more descriptive.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch for the missing out
.
I think logical
is the right term here, as opposed to physical
(see also the question on the forum that sparked this update), both commonly used in database-related topics. If we want to make it less technical (if slightly more ambiguous), we could use actual
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(Or remove it altogether.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think actual
makes it more ambiguous; if anything, I think logical
vs physical
is ambiguous. What's the physical change? Is it the bits being altered in the file containing the changed entity? Is it a struct field being rewritten? Or is, as Rory says in that topic, the creation of a whole graph entity? That's much more ambiguous to me, and so is logical
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's go with actual
then.
Thanks for the documentation updates. The preview documentation has now been torn down - reopening this PR will republish it. |
No description provided.