Discussion: Should we be read-only by default?

Related to #178

It may be worth to add a readOnlyTransact which is basically transact but setting / overriding the transaction config to have AccessMode.Read. However, IMHO, it only makes sense to add this if we use it for operations like single or list.

The pros of this would be to improve the performance of such operations for users having a multi-node cluster with nodes specialized in read-only operations. The cons are that this change may break existing applications without no-one noticing until execution (be it runtime or a test).

Finally note that if we do not do this, then people wanting to take advantage of the read-only optimizations need to write extra code. Whereas if we do, then people wanting to write inside a “read” query would need to add the extra code.

[geoffjohn11]

@BalmungSan Thanks for the feedback!

[BalmungSan]

@geoffjohn11 I like the idea of having both query and command and that query would be read-only by default. However, I took a quick look at your branch and I have some general comments:

• command also needs to be parametrized since you can get other things out of a command, like an ExecutionResult not only Unit also:
• command also needs to provide all the other operations like single since some users may combine writing and reading in a single query.
• query and command may share a common interface, but not a big deal.
• The creation of a command or a query MUST be shared, the algorithm of transforming a DefferedQuery into a Query is too complex to have it duplicated.