Apply configured `CodecRegistry` to `StatementBuilder`

[aakashacharya177]

I am using spring data cassandra 3.1.6 artifact and trying to use custom codec.

The insert method in StatementFactory class is not passing converter/codec registry to the statement builder class and hence insert query is not being formed properly.

StatementBuilder builder = StatementBuilder.of(QueryBuilder.insertInto(tableName).valuesByIds(Collections.emptyMap())).bind((statement, factory) -> {
Map<CqlIdentifier, Term> values = createTerms(insertNulls, object, factory);
return statement.valuesByIds(values);
}).apply((statement) -> {
return (RegularInsert)addWriteOptions((Insert)statement, options);
});

I am using spring data stax oss driver version 4.9.0

Can you please look into this and let us know if this has been fixed or we have a workaround for the same?

[mp911de]

Right now, we only support CodecRegistry.DEFAULT. We have around 53 occurrences that call StatementBuilder.build(…).

A majority of the work could be done by introducing a build(StatementBuilder) method on the template API level where you can plugin in your own CodecRegistry.

An alternative approach could be enhancing StatementFactory.of(…) to make it accept CodecRegistry. All calls to StatementFactory.of(…) originate from StatementFactory and CassandraConverter is already associated with a CodecRegistry so that seems the better approach.

[aakashacharya177]

Thanks for the response Mark.
Approach 2 seems to be a better approach where we can use the same codec registry of Cassandra converter.

We would be waiting for this enhancement. Can we get any tentative release plan?

[mp911de]

Submitting a pull request can speed up things. That is a change that we could include also in a service release. Check out https://calendar.spring.io/ for the release schedule.

[mipo256]

@mp911de We already can supply the CodecRegistry to StatementBuilder. So is this issue still relevant?
Although there are still places where we do not allow CodecRegistry customization, such is CassandraSimpleTypeHolder. Do not know if it is necessary or not though.

[mp911de]

All invocations to StatementBuilder use build() instead of build(ParameterHandling, CodecRegistry).

This ticket doesn't discuss the ability to specify CodecRegistry at StatementBuilder but the actual propagation of CodecRegistry. StatementBuilder should be extended also with a build(CodecRegistry) method to retain ParameterHandling defaulting.

Another thing that needs to be clarified is where CodecRegistry comes from. It could stem from CqlOperations, from SessionFactory or be configured on the CassandraTemplate level.

None is ideal, really. The most ideal approach would be to run StatementBuilder.build(CodecRegistry) within CqlOperations.execute(SessionCallback). While that would work well in the imperative style, any async or reactive code paths would be required to accept overhead of creating reactive/async wrapper types.

Happy to hear more opinions so that we can find the best approach.

[mp911de]

After revisiting this request, I found that using the actual CodecRegistry from the session is rather difficult. It is much easier (and makes more sense) to initialize StatementBuilder with the CodecRegistry configured at CassandraConverter as StatementFactory (the place that creates all StatementBuilder instances) has access to the converter already.