MySQL Bugs: #60011: FR: Consolidate tx_isolation and transaction-isolation

Bug #60011	FR: Consolidate tx_isolation and transaction-isolation
Submitted:	8 Feb 2011 17:53
Reporter:	Leandro Morgado	Email Updates:
Status:	Verified	Impact on me:	None
Category:	MySQL Server: Options	Severity:	S4 (Feature request)
Version:	all	OS:	Any
Assigned to:		CPU Architecture:	Any

Description:
A common gotcha is confusing the server variable tx_isolation with the server option transaction-isolation.

Most users expect variable and option names to match.

http://dev.mysql.com/doc/refman/5.1/en/server-options.html#option_mysqld_transaction-isola...
http://dev.mysql.com/doc/refman/5.1/en/server-system-variables.html#sysvar_tx_isolation

How to repeat:
To illustrate the potential for confusion:

To set this up at mysqld startup time, we need to use transaction-isolation, but to see the runtime server variables we need to use tx_isolation. Example:

[mysqld]
...
transaction-isolation = READ-UNCOMMITTED

mysql> SHOW VARIABLES LIKE "%isolation";
+---------------+------------------+
| Variable_name | Value            |
+---------------+------------------+
| tx_isolation  | READ-UNCOMMITTED |
+---------------+------------------+
1 row in set (0.00 sec)

Suggested fix:
Consolidate the diverging names so that:

1) Only one name is kept and the other deprecated

or

2) Both names are valid server options *and* server variables.

Please implement option (1) only. The other option just makes things more confusing.

Option (1) should not be implemented since it breaks backwards compatibility.

Option (3): Keep tx_isolation variable, but allow both tx_isolation and transaction-isolation in the my.cnf. Then fix all documentation to refer to tx_isolation only, and [optionally] (after a long time) deprecate transaction-isolation. This does not break backward compatibility and avoids the two-server-variables confusion.

(3) and (1) are the same depending on how you look at this.

I'd suggest you add warnings about the "appropriate variables being deprecated" in 5.6 (since this is not GA yet) and that in a _later_ version (since we don't know what will come after 5.6) the deprecated variables will be removed. Then documentation will be aligned with the change to be made, and after 5.6 you remove the old variable.

Personally I'd prefer keeping the longer "more readable variable", transaction_isolation.