[
https://issues.apache.org/jira/browse/CASSANDRA-18989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henrik Ingo updated CASSANDRA-18989:
------------------------------------
Description:
Note: I chose "bug" because I think this is a serious UX issue we should
consider. But strictly speaking this is a UX issue and technically the
implementation is working as designed. The UX conclusion rather is that the
desing needs improvement...
I'm submitting this based on observing [~antithesis-luis] creating a checker
with some accord transactions. A discussion that followed his experience is
here https://the-asf.slack.com/archives/C0459N9R5C6/p1698352614742079
The tl;dr is that users are likely to expect single SELECT queries, and maybe
even single UPDATE/INSERT to be consistent even if they neglect the
BEGIN...COMMIT around the single statement.
My proposed fix for improved UX is an ability to force or default also single
statements to be wrapper in an accord transaction.
There are two ways to implement this:
1. Add configuration option to reject queries that are not accord transactions.
This could be a per table or per keyspace option.
2. A per session setting that enables automatic transactions, combined with a
global setting to have this behavior as default. MySQL's AUTOCOMMIT is an
example of this approach.
My preference is #2.
was:
Note: I chose "bug" because I think this is a serious UX issue we should
consider. But strictly speaking this is a UX issue and technically the
implementation is working as designed. The UX conclusion rather is that the
desing needs improvement...
I'm submitting this based on observing [~alfprado] creating a checker with some
accord transactions. A discussion that followed his experience is here
https://the-asf.slack.com/archives/C0459N9R5C6/p1698352614742079
The tl;dr is that users are likely to expect single SELECT queries, and maybe
even single UPDATE/INSERT to be consistent even if they neglect the
BEGIN...COMMIT around the single statement.
My proposed fix for improved UX is an ability to force or default also single
statements to be wrapper in an accord transaction.
There are two ways to implement this:
1. Add configuration option to reject queries that are not accord transactions.
This could be a per table or per keyspace option.
2. A per session setting that enables automatic transactions, combined with a
global setting to have this behavior as default. MySQL's AUTOCOMMIT is an
example of this approach.
My preference is #2.
> Accord: Force transactions / automatic transactions
> ---------------------------------------------------
>
> Key: CASSANDRA-18989
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18989
> Project: Cassandra
> Issue Type: Bug
> Components: Accord
> Reporter: Henrik Ingo
> Priority: Normal
> Fix For: 5.x
>
>
> Note: I chose "bug" because I think this is a serious UX issue we should
> consider. But strictly speaking this is a UX issue and technically the
> implementation is working as designed. The UX conclusion rather is that the
> desing needs improvement...
> I'm submitting this based on observing [~antithesis-luis] creating a checker
> with some accord transactions. A discussion that followed his experience is
> here https://the-asf.slack.com/archives/C0459N9R5C6/p1698352614742079
> The tl;dr is that users are likely to expect single SELECT queries, and maybe
> even single UPDATE/INSERT to be consistent even if they neglect the
> BEGIN...COMMIT around the single statement.
> My proposed fix for improved UX is an ability to force or default also single
> statements to be wrapper in an accord transaction.
> There are two ways to implement this:
> 1. Add configuration option to reject queries that are not accord
> transactions. This could be a per table or per keyspace option.
> 2. A per session setting that enables automatic transactions, combined with a
> global setting to have this behavior as default. MySQL's AUTOCOMMIT is an
> example of this approach.
> My preference is #2.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
