Bolt V3 #517
Bolt V3 #517
Conversation
Added new messages and ability to write them into a network channel. Introduced Bolt V3 abstraction that uses new messages to execute execute queries, begin/commit/rollback transactions. Code does not yet use new metadata.
This is a better name because class holds a collection of bookmarks, not just a single one.
It always used V1 message format before.
Metadata keys are different in previous versions of the protocol. This commit makes it possible for keys to be defined by each Bolt protocol implementation. Also fixed couple unit tests and added license headers.
| @@ -66,10 +67,11 @@ | |||
| private CompletableFuture<Record> recordFuture; | |||
| private CompletableFuture<Throwable> failureFuture; | |||
|
|
|||
| public PullAllResponseHandler( Statement statement, RunResponseHandler runResponseHandler, Connection connection ) | |||
| public PullAllResponseHandler( Statement statement, RunResponseHandler runResponseHandler, String resultConsumedAfterMetadataKey, Connection connection ) | |||
There was a problem hiding this comment.
I can see why you have this key here,
but how about override this class and then have two implementation of extractResultSummary method? Versioning response handler sound a reasonable thing.
public ResultSummary extractResultSummary( Map<String,Value> metadata ) {
long resultAvailableAfter = runResponseHandler.resultAvailableAfter();
return MetadataUtil.extractSummary( statement, connection, resultAvailableAfter, metadata, T_LAST_KEY );
// or RESULT_COMSUMED_AFTER_KEY for v1 and v2
}
Similarly for RunResponseHandler, we can override onSuccess or onMeta?
There was a problem hiding this comment.
👍 I'll give this a try. Might especially be valuable if we add another response metadata field
There was a problem hiding this comment.
Made the metadata extraction utility versioned instead of passing string keys around. Creating classes felt a little to much - 3 new classes would need to be created just to override 2 string keys
|
|
||
| final Map<String,Value> metadata; | ||
|
|
||
| TransactionStartingMessage( Bookmarks bookmarks, Duration txTimeout, Map<String,Value> txMetadata ) |
There was a problem hiding this comment.
aha, smart interface to take all transaction related metadata
| ChannelPromise channelPromise = channel.newPromise(); | ||
| HelloResponseHandler handler = new HelloResponseHandler( channelPromise ); | ||
|
|
||
| assertThrows( IllegalArgumentException.class, () -> handler.onSuccess( singletonMap( "server", value( "WrongServerVersion" ) ) ) ); |
There was a problem hiding this comment.
Is it still required to have the server version parsed rather than simply record it as a simple message?
There was a problem hiding this comment.
Server version should not be needed for version comparisons in Bolt V3. It is just easier to still keep it as ServerVersion object for older protocol versions
Instead of passing string metadata keys around. This is needed because some metadata keys have changed in Bolt V3 compared to Bolt V1.
Added new message types and logic for handling them. New metadata like
tx_timeoutandtx_metadataare not used yet.Renamed
NettyConnectiontoDirectConnectionandBookmarktoBookmarks.