[Maria-developers] prefix matching for command-line options - how to disable?
Hi, We've got a bit of a problem with command-line option prefixes in the test suite. As you know, in MariaDB a command line option (the same applies to my.cnf too) doesn't need to be specified completely, it's sufficient to use an unambigous prefix of it. For example, 'net-retry-count=5' in my.cnf can be abbreviated as 'net-ret=5'. But not as 'net-re=5', the latter will fail with an error mysqld: ambiguous option '--net-re' (net_read_timeout, net_retry_count) This is the historical behavior of MySQL since about 2002. But it creates problems for plugins. InnoDB is particularly badly affected - it has lots of I_S plugins that are prefixes of other I_S plugins. For example: INNODB_BUFFER_PAGE INNODB_BUFFER_PAGE_LRU ... INNODB_CMP INNODB_CMPMEM INNODB_CMPMEM_RESET INNODB_CMP_PER_INDEX INNODB_CMP_PER_INDEX_RESET INNODB_CMP_RESET ... INNODB_SYS_FOREIGN INNODB_SYS_FOREIGN_COLS ... INNODB_SYS_TABLES INNODB_SYS_TABLESPACES INNODB_SYS_TABLESTATS also, it has plugins that match other plugin variables, like INNODB_LOCKS and innodb_locks_unsafe_for_binlog. As a result one cannot see or predict what these options will do. For example --enable-innodb-buffer-page might enable INNODB_BUFFER_PAGE plugin. Or it might enable INNODB_BUFFER_PAGE_LRU plugin - depending on which plugin will loaded (and will see and consume the option) first. And one cannot possibly disable INNODB_BUFFER_PAGE plugin, if the server will try to load INNODB_BUFFER_PAGE_LRU first. I see few solutions for this issue: 1. support a special suffix to option names that will disable prefix matching, for example: mysqld --enable-innodb-buffer-page! this will not match innodb-buffer-page-lru, so it's unambiguous. Of course, any dedicated character can be used, --enable-innodb-buffer-page$, or even a prefix --enable-exact-innodb-buffer-page, --enable-strict-innodb-buffer-page 2. add a special command-line option to disable prefix matching: mysqld --disable-getopt-prefix-matching --enable-innodb-buffer-page 3. do like mysql-5.7 is doing and completely remove support for prefix matching. In 5.7 one has to specified option names in full. I suspect that this is likely to break many exising setups. Opinions? Anybody cares about this obscure issue at all? Regards, Sergei
Indeed, its a really annoying behavior that can lead to bad surprises and similar issues can happen with command line tools that also supports abbreviations such as the mysql CLI, mysqladmin or mysqldump (eg: MDEV-7208). The first solution, to put a prefix/suffix on options would break compatibility with MySQL and other derivatives and add another level of complexion that most of the users wont even bother try to understand. The second solution seems the best to me : i think that such an option should be added even on 10.0 and even if it would be disabled by default on 10.0, there should be at least a warning throwed when an abbreviation is used telling how it was really interpreted and that abbreviation use is not recommended/deprecated ; that option would be enabled by default on 10.1 or at least this option would be enabled on the default/example my.cnf files supplied with MariaDB so it wouldnt break existing setups and could be disabled for peoples that wants to stick with their bad habits. The third solution makes sense if the second one requires much work to be implemented and doesnt seems to be that important, a simple deprecation warning for abbreviated commands on 10.0 would do the trick then but i suspect that doing that, does takes almost as implementing solution #2. ps: i never used abbreviations and never saw configurations or users using them (on purpose at least). Le 05/01/2015 20:20, Sergei Golubchik a écrit :
Hi,
We've got a bit of a problem with command-line option prefixes in the test suite. As you know, in MariaDB a command line option (the same applies to my.cnf too) doesn't need to be specified completely, it's sufficient to use an unambigous prefix of it.
For example, 'net-retry-count=5' in my.cnf can be abbreviated as 'net-ret=5'. But not as 'net-re=5', the latter will fail with an error
mysqld: ambiguous option '--net-re' (net_read_timeout, net_retry_count)
This is the historical behavior of MySQL since about 2002.
But it creates problems for plugins. InnoDB is particularly badly affected - it has lots of I_S plugins that are prefixes of other I_S plugins. For example:
INNODB_BUFFER_PAGE INNODB_BUFFER_PAGE_LRU ... INNODB_CMP INNODB_CMPMEM INNODB_CMPMEM_RESET INNODB_CMP_PER_INDEX INNODB_CMP_PER_INDEX_RESET INNODB_CMP_RESET ... INNODB_SYS_FOREIGN INNODB_SYS_FOREIGN_COLS ... INNODB_SYS_TABLES INNODB_SYS_TABLESPACES INNODB_SYS_TABLESTATS
also, it has plugins that match other plugin variables, like INNODB_LOCKS and innodb_locks_unsafe_for_binlog.
As a result one cannot see or predict what these options will do. For example --enable-innodb-buffer-page might enable INNODB_BUFFER_PAGE plugin. Or it might enable INNODB_BUFFER_PAGE_LRU plugin - depending on which plugin will loaded (and will see and consume the option) first. And one cannot possibly disable INNODB_BUFFER_PAGE plugin, if the server will try to load INNODB_BUFFER_PAGE_LRU first.
I see few solutions for this issue:
1. support a special suffix to option names that will disable prefix matching, for example:
mysqld --enable-innodb-buffer-page!
this will not match innodb-buffer-page-lru, so it's unambiguous. Of course, any dedicated character can be used, --enable-innodb-buffer-page$, or even a prefix --enable-exact-innodb-buffer-page, --enable-strict-innodb-buffer-page
2. add a special command-line option to disable prefix matching:
mysqld --disable-getopt-prefix-matching --enable-innodb-buffer-page
3. do like mysql-5.7 is doing and completely remove support for prefix matching. In 5.7 one has to specified option names in full. I suspect that this is likely to break many exising setups.
Opinions? Anybody cares about this obscure issue at all?
Regards, Sergei
Hi, Jean! On Jan 06, Jean Weisbuch wrote:
Indeed, its a really annoying behavior that can lead to bad surprises and similar issues can happen with command line tools that also supports abbreviations such as the mysql CLI, mysqladmin or mysqldump (eg: MDEV-7208).
1. support a special suffix to option names that will disable prefix matching, for example: mysqld --enable-innodb-buffer-page!
The first solution, to put a prefix/suffix on options would break compatibility with MySQL and other derivatives and add another level of complexion that most of the users wont even bother try to understand.
It will break compatibility with 5.7 (because 5.7 doesn't do prefix matching), but it'll be perfectly compatible with 5.6 and earlier versions, because '!' was invalid on the command line, so adding new semantics for it doesn't introduce incompatibilities. And it's compatible with existing my.cnf files. But I agree about complexity, I don't like that either.
2. add a special command-line option to disable prefix matching: mysqld --disable-getopt-prefix-matching --enable-innodb-buffer-page
The second solution seems the best to me : i think that such an option should be added even on 10.0 and even if it would be disabled by default on 10.0, there should be at least a warning throwed when an abbreviation is used telling how it was really interpreted and that abbreviation use is not recommended/deprecated ; that option would be enabled by default on 10.1 or at least this option would be enabled on the default/example my.cnf files supplied with MariaDB so it wouldnt break existing setups and could be disabled for peoples that wants to stick with their bad habits.
Okay, thanks. It feels a bit strange to control command line option parsing with a command line option. But it'll work.
3. do like mysql-5.7 is doing and completely remove support for prefix matching. In 5.7 one has to specified option names in full. I suspect that this is likely to break many exising setups.
The third solution makes sense if the second one requires much work to be implemented and doesnt seems to be that important, a simple deprecation warning for abbreviated commands on 10.0 would do the trick then but i suspect that doing that, does takes almost as implementing solution #2.
ps: i never used abbreviations and never saw configurations or users using them (on purpose at least).
Yes, I don't think that many use that on purpose. But they're easy to use unintentionally. Like one writes max-length-for-sort=2K and that works, so he believes that's the correct option name (while in fact it's max-length-for-sort-data). Or myisam-recover=FORCE. It's even documented in the manual as "myisam-recover", while the correct full name is "myisam-recover-option". Regards, Sergei
2015-01-06 6:22 GMT+02:00 Jean Weisbuch <jean@phpnet.org>:
The second solution seems the best to me : i think that such an option should be added even on 10.0 and even if it would be disabled by default on 10.0, there should be at least a warning throwed when an abbreviation is used telling how it was really interpreted and that abbreviation use is not recommended/deprecated ; that option would be enabled by default on 10.1 or at least this option would be enabled on the default/example my.cnf files supplied with MariaDB so it wouldnt break existing setups and could be disabled for peoples that wants to stick with their bad habits.
The third solution makes sense if the second one requires much work to be implemented and doesnt seems to be that important, a simple deprecation warning for abbreviated commands on 10.0 would do the trick then but i suspect that doing that, does takes almost as implementing solution #2.
I agree with both paragraphs above.
ps: i never used abbreviations and never saw configurations or users using them (on purpose at least).
Me too. I didn't even know such a feature existed in MySQL/MariaDB. In some tools where I come across auto-abbreviations I've disliked it. It is difficult from documentation point-of-view to read and understand if two commands do the same thing or not. If people are too lazy to write long commands, then autocompletion is a much better solution. I like very much how git does this: it has both autocompletion and context-aware help if you run a command that was wrong and maybe misspelled.
participants (3)
-
Jean Weisbuch -
Otto Kekäläinen -
Sergei Golubchik