Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
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
Original file line number Diff line number Diff line change
@@ -1,9 +1,6 @@
[[cmd-AddAnnotation]]
===== Add annotation
Add new node <<AddAnnotation.newAnnotation>> to <<AddAnnotation.parent>>'s annotations at <<AddAnnotation.index>>.
<<AddAnnotation.newAnnotation>> might be a single node or an arbitrary complex subtree.
All nodes in that subtree MUST be new, i.e. their id MUST NOT exist in the repository.
Nodes in that subtree MAY have references to already existing nodes, and already existing nodes MAY have references to nodes in that subtree.{fn-org327}

[cols="a,a"]
|===
Expand All @@ -20,9 +17,14 @@ include::AddAnnotation-diagram.adoc[]
[[AddAnnotation.parent, `parent`]]parent:: <<targetNodeType>>

[[AddAnnotation.newAnnotation, `newAnnotation`]]newAnnotation:: <<chunkType>>
Subtree to form a new annotation.
The _anchor node_ MUST contain the <<AddAnnotation.parent>> as _parent_.{fn-org357}
All nodes in that subtree MUST be <<new-nodes>>.

[[AddAnnotation.index, `index`]]index:: <<indexType>>

[[AddAnnotation.split, `split`]]split:: <<splitFlagType>>

[[AddAnnotation.commandId]]commandId:: <<commandIdType>>

[[AddAnnotation.protocolMessages]]protocolMessages:: <<protocolMessagesType>>
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -18,6 +18,8 @@ All other annotations inside <<AnnotationAdded.parent>>'s annotations with index

[[AnnotationAdded.index, `index`]]index:: <<indexType>>

[[AnnotationAdded.split, `split`]]split:: <<splitFlagType>>

[[AnnotationAdded.originCommands]]originCommands:: <<commandSourceType>>[]

[[AnnotationAdded.sequenceNumber]]sequenceNumber:: <<event-sequence-number>>
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -22,6 +22,8 @@ Nodes in that subtree MAY have references to already existing nodes, and already

[[AnnotationReplaced.index, `index`]]index:: <<indexType>>

[[AnnotationReplaced.split, `split`]]split:: <<splitFlagType>>

[[AnnotationReplaced.originCommands]]originCommands:: <<commandSourceType>>[]

[[AnnotationReplaced.sequenceNumber]]sequenceNumber:: <<event-sequence-number>>
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -3,11 +3,6 @@
Delete current node <<ReplaceAnnotation.replacedAnnotation>>{fn-org371} at <<ReplaceAnnotation.parent>>'s annotations at <<ReplaceAnnotation.index>>, and all its descendants (including annotation instances).
Does NOT change references to any of the deleted nodes.{fn-org285}

Replace existing node <<ReplaceAnnotation.replacedAnnotation>> inside <<ReplaceAnnotation.parent>>'s annotations at <<ReplaceAnnotation.index>> with new node <<ReplaceAnnotation.newAnnotation>>.
<<ReplaceAnnotation.newAnnotation>> might be a single node or an arbitrary complex subtree.
All nodes in that subtree MUST be new, i.e. their id MUST NOT exist in the repository.
Nodes in that subtree MAY have references to already existing nodes, and already existing nodes MAY have references to nodes in that subtree.{fn-org327}

[cols="a,a"]
|===
|Before |After
Expand All @@ -21,13 +16,18 @@ include::ReplaceAnnotation-diagram.adoc[]
[horizontal]
.Parameters
[[ReplaceAnnotation.newAnnotation, `newAnnotation`]]newAnnotation:: <<chunkType>>
Subtree to form a new annotation.
The _anchor node_ MUST contain the <<ReplaceAnnotation.parent>> as _parent_.{fn-org357}
All nodes in that subtree MUST either be <<new-nodes>> or <<reused-nodes>>.

[[ReplaceAnnotation.parent, `parent`]]parent:: <<targetNodeType>>

[[ReplaceAnnotation.index, `index`]]index:: <<indexType>>

[[ReplaceAnnotation.replacedAnnotation, `replacedAnnotation`]]replacedAnnotation:: <<targetNodeType>>

[[ReplaceAnnotation.split, `split`]]split:: <<splitFlagType>>

[[ReplaceAnnotation.commandId]]commandId:: <<commandIdType>>

[[ReplaceAnnotation.protocolMessages]]protocolMessages:: <<protocolMessagesType>>
Expand Down
8 changes: 5 additions & 3 deletions delta/commandsEvents/children/AddChild/AddChild.adoc
Original file line number Diff line number Diff line change
@@ -1,9 +1,6 @@
[[cmd-AddChild]]
===== Add child
Add new node <<AddChild.newChild>> to <<AddChild.parent>> in <<AddChild.containment>> at <<AddChild.index>>.
<<AddChild.newChild>> might be a single node or an arbitrary complex subtree.
All nodes in that subtree MUST be new, i.e. their id MUST NOT exist in the repository.
Nodes in that subtree MAY have references to already existing nodes, and already existing nodes MAY have references to nodes in that subtree.{fn-org327}

[cols="a,a"]
|===
Expand All @@ -20,11 +17,16 @@ include::AddChild-diagram.adoc[]
[[AddChild.parent, `parent`]]parent:: <<targetNodeType>>

[[AddChild.newChild, `newChild`]]newChild:: <<chunkType>>
Subtree to form a new child.
The _anchor node_ MUST contain the <<AddChild.parent>> as _parent_.{fn-org357}
All nodes in that subtree MUST be <<new-nodes>>.

[[AddChild.containment, `containment`]]containment:: <<metaPointerType>>

[[AddChild.index, `index`]]index:: <<indexType>>

[[AddChild.split, `split`]]split:: <<splitFlagType>>

[[AddChild.commandId]]commandId:: <<commandIdType>>

[[AddChild.protocolMessages]]protocolMessages:: <<protocolMessagesType>>
Expand Down
2 changes: 2 additions & 0 deletions delta/commandsEvents/children/AddChild/ChildAdded.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -20,6 +20,8 @@ All other children inside <<ChildAdded.parent>>'s <<ChildAdded.containment>> wit

[[ChildAdded.index, `index`]]index:: <<indexType>>

[[ChildAdded.split, `split`]]split:: <<splitFlagType>>

[[ChildAdded.originCommands]]originCommands:: <<commandSourceType>>[]

[[ChildAdded.sequenceNumber]]sequenceNumber:: <<event-sequence-number>>
Expand Down
2 changes: 2 additions & 0 deletions delta/commandsEvents/children/ReplaceChild/ChildReplaced.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -25,6 +25,8 @@ Nodes in that subtree MAY have references to already existing nodes, and already

[[ChildReplaced.index, `index`]]index:: <<indexType>>

[[ChildReplaced.split, `split`]]split:: <<splitFlagType>>

[[ChildReplaced.originCommands]]originCommands:: <<commandSourceType>>[]

[[ChildReplaced.sequenceNumber]]sequenceNumber:: <<event-sequence-number>>
Expand Down
8 changes: 5 additions & 3 deletions delta/commandsEvents/children/ReplaceChild/ReplaceChild.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -4,9 +4,6 @@ Delete current child <<ReplaceChild.replacedChild>>{fn-org371} inside <<ReplaceC
Does NOT change references to any of the deleted nodes.{fn-org285}

Replace existing node <<ReplaceChild.replacedChild>> inside <<ReplaceChild.parent>>'s <<ReplaceChild.containment>> at <<ReplaceChild.index>> with new node <<ReplaceChild.newChild>>.
`newChild` might be a single node or an arbitrary complex subtree.
All nodes in that subtree MUST be new, i.e. their id MUST NOT exist in the repository.
Nodes in that subtree MAY have references to already existing nodes, and already existing nodes MAY have references to nodes in that subtree.{fn-org327}

[cols="a,a"]
|===
Expand All @@ -21,6 +18,9 @@ include::ReplaceChild-diagram.adoc[]
[horizontal]
.Parameters
[[ReplaceChild.newChild, `newChild`]]newChild:: <<chunkType>>
Subtree to form a new child.
The _anchor node_ MUST contain the <<ReplaceChild.parent>> as _parent_.{fn-org357}
All nodes in that subtree MUST either be <<new-nodes>> or <<reused-nodes>>.

[[ReplaceChild.parent, `parent`]]parent:: <<targetNodeType>>

Expand All @@ -30,6 +30,8 @@ include::ReplaceChild-diagram.adoc[]

[[ReplaceChild.replacedChild, `replacedChild`]]replacedChild:: <<targetNodeType>>

[[ReplaceChild.split, `split`]]split:: <<splitFlagType>>

[[ReplaceChild.commandId]]commandId:: <<commandIdType>>

[[ReplaceChild.protocolMessages]]protocolMessages:: <<protocolMessagesType>>
Expand Down
16 changes: 1 addition & 15 deletions delta/commandsEvents/commands.adoc
Original file line number Diff line number Diff line change
@@ -1,21 +1,7 @@
[[commands]]
=== Commands

==== Lifecycle
[plantuml, commandsLifecycle, svg]
----
hide empty description

[*] -> Created: <i>client</i>\ncreates
Created -> Sent: <i>client</i>\nsends

Sent --> Failed: <i>repository</i>\ninvalid command
Failed -> [*]: <i>client</i>\ndiscards

Sent -> Received: <i>repository</i>\nreceives
Received -> Processed: <i>repository</i> emits event,\n<i>client</i> receives event
Processed --> [*]: <i>client</i>\ndiscards
----
include::../continuedChunk/ChunkedCommand.adoc[]

include::partitions/CommandPartitions.adoc[]

Expand Down
2 changes: 2 additions & 0 deletions delta/commandsEvents/events.adoc
Original file line number Diff line number Diff line change
@@ -1,6 +1,8 @@
[[events]]
=== Events

include::../continuedChunk/ChunkedEvent.adoc[]

include::partitions/EventPartitions.adoc[]

include::nodes/EventNodes.adoc[]
Expand Down
12 changes: 8 additions & 4 deletions delta/commandsEvents/partitions/AddPartition/AddPartition.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -15,10 +15,14 @@ include::AddPartition-diagram.adoc[]
[horizontal]
.Parameters
[[AddPartition.newPartition, `newPartition`]]newPartition:: <<chunkType>>
{fn-org327} root node to form a new partition.
The root node MUST NOT contain a _parent_ (as this is a partition, thus cannot have a parent).
All nodes in that subtree MUST be new, i.e. their id MUST NOT exist in the repository.
Nodes in that subtree MAY have references to already existing nodes, and already existing nodes MAY have references to nodes in that subtree.{fn-org327}
Subtree to form a new partition.
The _anchor node_ MUST NOT contain a _parent_ (as this is a partition, thus cannot have a parent).
All nodes in that subtree MUST be <<new-nodes, new nodes>>.
+
NOTE: This parameter differs from the <<PartitionAdded.newPartition, corresponding event parameter>>:
The command's parameter contains a whole subtree, whereas the event's parameter only contains the partition node.

[[AddPartition.split, `split`]]split:: <<splitFlagType>>

[[AddPartition.commandId]]commandId:: <<commandIdType>>
Id of this command.
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -9,7 +9,9 @@ This client is now subscribed to any changes to <<PartitionAdded.newPartition>>

[horizontal]
.Parameters
[[PartitionAdded.newPartition, `newPartition`]]newPartition:: <<chunkType>>
[[PartitionAdded.newPartition, `newPartition`]]newPartition:: <<shallowChunkType>>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see no reason to introduce a new type for this, we can (as we already did) use the << chunkType >> for this, with the explanation we already had, saying that the containments, references and annotations are empty.
Feels like overkill.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We use it at more than one place, so I'd like to unify the description.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

At all other places I found it used in the spec, I don't think it should be there, as I said in several comments.

NOTE: This parameter differs from the <<AddPartition.newPartition, corresponding command parameter>>:
The command's parameter contains a whole subtree, whereas the event's parameter only contains the partition node.

[[PartitionAdded.originCommands]]originCommands:: <<commandSourceType>>[]

Expand Down
27 changes: 27 additions & 0 deletions delta/continuedChunk/ChunkedCommand.adoc
Original file line number Diff line number Diff line change
@@ -0,0 +1,27 @@
[[cmd-ChunkedCommand]]
==== Chunked Command
A <<continuedChunk>> for one of the following <<splittableMessage, splittable>> commands:

* <<cmd-AddPartition>> <<AddPartition.newPartition>>
* <<cmd-AddChild>> <<AddChild.newChild>>
* <<cmd-ReplaceChild>> <<ReplaceChild.newChild>>
* <<cmd-AddAnnotation>> <<AddAnnotation.parent>>
* <<cmd-ReplaceAnnotation>> <<ReplaceAnnotation.newAnnotation>>

.Technical name
`ChunkedCommand`

[horizontal]
.Parameters
[[ChunkedCommand.chunk, `chunk`]]chunk:: <<chunkType>> or <<shallowChunkType>>
The continued chunk.
MUST adhere to the same constraints as the related <<splittableMessage>>'s chunk.

[[ChunkedCommand.continuedChunkCompleted, `continuedChunkCompleted`]]continuedChunkCompleted:: <<continuedChunkCompletedFlagType>>

[[ChunkedCommand.continuedChunkSequenceNumber, `continuedChunkSequenceNumber`]]continuedChunkSequenceNumber:: <<continuedChunkSequenceNumberType>>

[[ChunkedCommand.commandId]]commandId:: <<commandIdType>>
Id of the related <<splittableMessage, splittable command>>

[[ChunkedCommand.protocolMessages, `protocolMessages`]]protocolMessages:: <<protocolMessagesType>>
27 changes: 27 additions & 0 deletions delta/continuedChunk/ChunkedEvent.adoc
Original file line number Diff line number Diff line change
@@ -0,0 +1,27 @@
[[evnt-ChunkedEvent]]
==== Chunked Event
A <<continuedChunk>> for one of the following <<splittableMessage, splittable>> events:

* <<evnt-PartitionAdded>> <<PartitionAdded.newPartition>>
* <<evnt-ChildAdded>> <<ChildAdded.newChild>>
* <<evnt-ChildReplaced>> <<ChildReplaced.newChild>>
* <<evnt-AnnotationAdded>> <<AnnotationAdded.newAnnotation>>
* <<evnt-AnnotationReplaced>> <<AnnotationReplaced.newAnnotation>>

.Technical name
`ChunkedEvent`

[horizontal]
.Parameters
[[ChunkedEvent.chunk, `chunk`]]chunk:: <<chunkType>> or <<shallowChunkType>>
The continued chunk.
MUST adhere to the same constraints as the related <<splittableMessage>>'s chunk.

[[ChunkedEvent.continuedChunkCompleted, `continuedChunkCompleted`]]continuedChunkCompleted:: <<continuedChunkCompletedFlagType>>

[[ChunkedEvent.chunkedEventSequenceNumber]]chunkedEventSequenceNumber:: <<event-sequence-number>>
Sequence number of the related <<splittableMessage, splittable event>>

[[ChunkedEvent.sequenceNumber]]sequenceNumber:: <<event-sequence-number>>

[[ChunkedEvent.protocolMessages]]protocolMessages:: <<protocolMessagesType>>
24 changes: 24 additions & 0 deletions delta/continuedChunk/ChunkedQueryResponse.adoc
Original file line number Diff line number Diff line change
@@ -0,0 +1,24 @@
[[qry-ChunkedQueryResponse]]
==== Chunked query response
A <<continuedChunk>> for a <<splittableMessage, splittable>> response of one of the following queries:

* <<qry-SubscribeToPartitionContents>> response <<SubscribeToPartitionContents.contents>>
* <<qry-ListPartitions>> response <<ListPartitions.partitions>>

.Technical name
`ChunkedQueryResponse`

[horizontal]
.Response parameters
[[ChunkedQueryResponse.chunk, `chunk`]]chunk:: <<chunkType>> or <<shallowChunkType>>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I find it very bad practice to have a property with a join type. Also, I do not see why we need << shallowChunkType>> here. All chunks are full << chunkType >>'s

The continued chunk.
MUST adhere to the same constraints as the related <<splittableMessage>>'s chunk.

[[ChunkedQueryResponse.continuedChunkCompleted, `continuedChunkCompleted`]]continuedChunkCompleted:: <<continuedChunkCompletedFlagType>>

[[ChunkedQueryResponse.continuedChunkSequenceNumber, `continuedChunkSequenceNumber`]]continuedChunkSequenceNumber:: <<continuedChunkSequenceNumberType>>

[[ChunkedQueryResponse.queryId, `queryId`]]queryId:: <<queryIdType>>
Id of the related <<splittableMessage, splittable query>>

[[ChunkedQueryResponse.protocolMessages, `protocolMessages`]]protocolMessages:: <<protocolMessagesType>>
66 changes: 61 additions & 5 deletions delta/description.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -73,20 +73,76 @@ The repository also sends out the same events to subscribed clients, thus _not_

[[message, message]]
=== Message characteristics
Each message is atomic; it cannot be split.

[[messageAtomicity]]
.Atomicity
Most messages are atomic; they cannot be split.
The exceptions are <<splittableMessage, splittable messages>>.

[[messageIdentity, message identity]]
.Message identity
Each message has some id unique to the <<participation>>:

* Queries have a _query id_.
* Commands have a _command id_.{fn-org305}
* Events have _command sources_.{fn-org306}
* Queries have a <<queryIdType>> (for <<qry-ChunkedQueryResponse>> together with its <<continuedChunkSequenceNumberType>>).
* Commands have a <<commandIdType>> (for <<cmd-ChunkedCommand>> together with its <<continuedChunkSequenceNumberType>>).{fn-org305}
* Events have <<eventSequenceType>>.{fn-org423}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And respponses have a unique responseQueryId


[[technicalName, technical name]]
.Technical name
Every kind of message has a unique _technical name_.
The technical name is a valid programming language identifier as described for <<{m3}.adoc#IKeyed, IKeyed>>.
Each binding to a specific protocol might use the technical name in a different way.
For example, a JSON binding might have a member containing the technical name of the message, or a Protobuf binding might use the technical name as type name.

Each message optionally can have one or more _[[protocolMessage, protocol message]]protocol message_ consisting of:{fn-org331}{fn-org332}
[[splittableMessage, splittable message]]
==== Splittable messages
All messages containing a <<chunkType>> or <<shallowChunkType>>.

A client or repository CAN decide to split up a _splittable message_ if that message would exceed the acceptable message size.
LionWeb does not define the acceptable message size, it SHOULD be a parameter for each implementation.

All _splittable messages_ contain a <<splitFlagType>>.
If the flag is `false`, the splittable message is self-contained.
If the flag is `true`, one or more <<continuedChunk>> messages will follow.{fn-org425}

_Splittable messages_ include:

Queries::
* <<qry-SubscribeToPartitionContents>> response <<SubscribeToPartitionContents.contents>>
* <<qry-ListPartitions>> response <<ListPartitions.partitions>>

Commands::
* <<cmd-AddPartition>> <<AddPartition.newPartition>>
* <<cmd-AddChild>> <<AddChild.newChild>>
* <<cmd-ReplaceChild>> <<ReplaceChild.newChild>>
* <<cmd-AddAnnotation>> <<AddAnnotation.parent>>
* <<cmd-ReplaceAnnotation>> <<ReplaceAnnotation.newAnnotation>>

Events::
* <<evnt-ChildAdded>> <<ChildAdded.newChild>>
* <<evnt-ChildReplaced>> <<ChildReplaced.newChild>>
* <<evnt-AnnotationAdded>> <<AnnotationAdded.newAnnotation>>
* <<evnt-AnnotationReplaced>> <<AnnotationReplaced.newAnnotation>>

[[continuedChunk, continued chunk]]
.Continued chunks
_Continued chunks_ continue the chunk from the related <<splittableMessage>>.
Each _continued chunk_ refers to the <<splittableMessage>> it belongs to.
The _continued chunk_ contains a chunk, a consecutive sequence number, and a <<continuedChunkCompletedFlagType>> to signal whether it is the last _continued chunk_, or more will follow.
If the flag is `true`, this is the last _continued chunk_.
If the flag is `false`, one or more _continued chunk_ messages will follow.{fn-org425}

There MUST NOT be any message in the same <<channel>> between the _chunked message_ and all related _continued chunks_.

_Continued chunks_ include:

* <<qry-ChunkedQueryResponse>>
* <<cmd-ChunkedCommand>>
* <<evnt-ChunkedEvent>>

[[protocolMessage, protocol message]]
==== Protocol messages
Each message optionally can have one or more _protocol message_ consisting of:{fn-org331}{fn-org332}

* [[protocolMessage.kind]]`kind` is an <<{m3}.adoc#identifiers, identifier>>-compatible string identifying the message type.
Some message kinds are pre-defined in this specification.
Expand Down
Loading