[Maria-developers] Intermediate status for test cases merge
Hi! So far I processed 431 test cases from the main suite. Most of them are up to date, a few merged without problems, a few tests fail (bugs reported), a few need extra analysis. There are a few items which I'd like to discuss: - INSERT DELAYED is deprecated in 5.6, do we want to deprecate it too? - SHOW PROFILE is deprecated in 5.6, do we want to deprecate it too? - YEAR(2) is deprecated in 5.6, do we want to deprecate it too? Monty suggests that we shouldn't deprecate it. I find it Ok too. Reasons for YEAR(2) deprecation are not obvious, relevant worklog is private. Relevant revision comment says: "YEAR(2) is a subject to deprecation since it has ill design." - EXPLAIN gives NULL in Extra column in 5.6 (empty string in 10.0), do we want behave similarly? - Do we want to merge fix for BUG#60269 - mysql should reject attempts to create system tables in incorrect engine http://bugs.mysql.com/bug.php?id=60269 - NO_ENGINE_SUBSTITUTION is default mode in 5.6 now, do we want it be default too? - 5.6 has many updates to default values, do we like to merge them too? Thanks, Sergey
Hi, Sergey! On Mar 11, Sergey Vojtovich wrote:
Hi!
So far I processed 431 test cases from the main suite. Most of them are up to date, a few merged without problems, a few tests fail (bugs reported), a few need extra analysis.
There are a few items which I'd like to discuss: - INSERT DELAYED is deprecated in 5.6, do we want to deprecate it too?
Probably not, it's being used. Apparently, it's about as popular as GIS (if the feedback data are any indication).
- SHOW PROFILE is deprecated in 5.6, do we want to deprecate it too?
I'm not sure. It's being used too, although less than INSERT DELAYED, but more than XML functions :) Perhaps we can deprecate it in 10.1 or rewrite to use P_S...
- YEAR(2) is deprecated in 5.6, do we want to deprecate it too? Monty suggests that we shouldn't deprecate it. I find it Ok too. Reasons for YEAR(2) deprecation are not obvious, relevant worklog is private. Relevant revision comment says: "YEAR(2) is a subject to deprecation since it has ill design."
I'd deprecate it - I agree about "ill design", it has lots of gotchas that are literally impossible to fix. In some cases it seems to work, but it's enough to change the query slightly - and it won't.
- EXPLAIN gives NULL in Extra column in 5.6 (empty string in 10.0), do we want behave similarly?
I don't see why.
- Do we want to merge fix for BUG#60269 - mysql should reject attempts to create system tables in incorrect engine http://bugs.mysql.com/bug.php?id=60269
No. That was lp:790513 for us, and I've fixed it differently. We have a test for this - t/plugin_innodb.test
- NO_ENGINE_SUBSTITUTION is default mode in 5.6 now, do we want it be default too?
May be. What do you think?
- 5.6 has many updates to default values, do we like to merge them too?
What was chanaged? What do you think? Regards, Sergei
Hi Sergei, On Tue, Mar 18, 2014 at 05:25:59PM +0100, Sergei Golubchik wrote:
Hi, Sergey!
On Mar 11, Sergey Vojtovich wrote:
Hi!
So far I processed 431 test cases from the main suite. Most of them are up to date, a few merged without problems, a few tests fail (bugs reported), a few need extra analysis.
There are a few items which I'd like to discuss: - INSERT DELAYED is deprecated in 5.6, do we want to deprecate it too?
Probably not, it's being used. Apparently, it's about as popular as GIS (if the feedback data are any indication). Ok.
- SHOW PROFILE is deprecated in 5.6, do we want to deprecate it too?
I'm not sure. It's being used too, although less than INSERT DELAYED, but more than XML functions :)
Perhaps we can deprecate it in 10.1 or rewrite to use P_S...
Ok, should I create jira task?
- YEAR(2) is deprecated in 5.6, do we want to deprecate it too? Monty suggests that we shouldn't deprecate it. I find it Ok too. Reasons for YEAR(2) deprecation are not obvious, relevant worklog is private. Relevant revision comment says: "YEAR(2) is a subject to deprecation since it has ill design."
I'd deprecate it - I agree about "ill design", it has lots of gotchas that are literally impossible to fix. In some cases it seems to work, but it's enough to change the query slightly - and it won't.
OTOH it requires less storage, which is a pro. It looks well-defined, that is 0-69 are 2000-2069 and 70-99 are 1970-1999. Though I can't judge the design. Monty likes it. Should I create jira task?
- EXPLAIN gives NULL in Extra column in 5.6 (empty string in 10.0), do we want behave similarly?
I don't see why.
Ok.
- Do we want to merge fix for BUG#60269 - mysql should reject attempts to create system tables in incorrect engine http://bugs.mysql.com/bug.php?id=60269
No. That was lp:790513 for us, and I've fixed it differently. We have a test for this - t/plugin_innodb.test
Ok, will disregard this fix.
- NO_ENGINE_SUBSTITUTION is default mode in 5.6 now, do we want it be default too?
May be. What do you think?
I'd say these days storage engines have way too different semantics. E.g. if user requests FEDERATED but gets MyISAM further queries will return unexpected results. I believe it is a good idea to make it default too.
- 5.6 has many updates to default values, do we like to merge them too?
What was chanaged?
A lot. I'd better prepare list and start another thread.
What do you think? I think most of these changes are worthy.
Regards, Sergey
Hi, Sergey! On Mar 21, Sergey Vojtovich wrote:
On Tue, Mar 18, 2014 at 05:25:59PM +0100, Sergei Golubchik wrote:
On Mar 11, Sergey Vojtovich wrote:
- SHOW PROFILE is deprecated in 5.6, do we want to deprecate it too?
I'm not sure. It's being used too, although less than INSERT DELAYED, but more than XML functions :)
Perhaps we can deprecate it in 10.1 or rewrite to use P_S... Ok, should I create jira task?
Yes, please!
- YEAR(2) is deprecated in 5.6, do we want to deprecate it too? Monty suggests that we shouldn't deprecate it. I find it Ok too. Reasons for YEAR(2) deprecation are not obvious, relevant worklog is private. Relevant revision comment says: "YEAR(2) is a subject to deprecation since it has ill design."
I'd deprecate it - I agree about "ill design", it has lots of gotchas that are literally impossible to fix. In some cases it seems to work, but it's enough to change the query slightly - and it won't. OTOH it requires less storage, which is a pro. It looks well-defined, that is 0-69 are 2000-2069 and 70-99 are 1970-1999. Though I can't judge the design. Monty likes it. Should I create jira task?
The fundamental design flaw - only the Field itself knows that it's YEAR(2), no item knows it. So, as long as you use YEAR(2) in any expression - it loses its magic powers: MariaDB [test]> create table t1 (y2 year(2), y4 year(4)); Query OK, 0 rows affected, 1 warning (0.00 sec) MariaDB [test]> insert t1 values (10, 2010); Query OK, 1 row affected (0.00 sec) MariaDB [test]> select * from t1; +------+------+ | y2 | y4 | +------+------+ | 10 | 2010 | +------+------+ 1 row in set (0.00 sec) MariaDB [test]> select y2 = 2010, y4=2010, y2=y4 from t1; +-----------+---------+-------+ | y2 = 2010 | y4=2010 | y2=y4 | +-----------+---------+-------+ | 1 | 1 | 1 | +-----------+---------+-------+ 1 row in set (0.00 sec) MariaDB [test]> select y2+0 = 2010, y4+0=2010, y2+0=y4+0 from t1; +-------------+-----------+-----------+ | y2+0 = 2010 | y4+0=2010 | y2+0=y4+0 | +-------------+-----------+-----------+ | 0 | 1 | 0 | +-------------+-----------+-----------+ 1 row in set (0.00 sec) Think also of Item_cache, Item_ref, GROUP BY (with temp tables), subqueries - I really don't know in what cases YEAR(2) works and in what it doesn't.
- NO_ENGINE_SUBSTITUTION is default mode in 5.6 now, do we want it be default too?
May be. What do you think? I'd say these days storage engines have way too different semantics. E.g. if user requests FEDERATED but gets MyISAM further queries will return unexpected results.
I believe it is a good idea to make it default too.
Okay. Old idea of SQL_MODE always was that empty set is always the default. I mean, all sql-mode values were selected this way (e.g. NO_ENGINE_SUBSTITUTION vs. ALLOW_ENGINE_SUBSTITUTION). But I agree, we cannot keep this forever... Regards, Sergei
Hi Sergei, On Fri, Mar 21, 2014 at 12:28:11PM +0100, Sergei Golubchik wrote:
Hi, Sergey!
On Mar 21, Sergey Vojtovich wrote:
On Tue, Mar 18, 2014 at 05:25:59PM +0100, Sergei Golubchik wrote:
On Mar 11, Sergey Vojtovich wrote:
- SHOW PROFILE is deprecated in 5.6, do we want to deprecate it too?
I'm not sure. It's being used too, although less than INSERT DELAYED, but more than XML functions :)
Perhaps we can deprecate it in 10.1 or rewrite to use P_S... Ok, should I create jira task?
Yes, please! FYI: https://mariadb.atlassian.net/browse/MDEV-5936
- YEAR(2) is deprecated in 5.6, do we want to deprecate it too? Monty suggests that we shouldn't deprecate it. I find it Ok too. Reasons for YEAR(2) deprecation are not obvious, relevant worklog is private. Relevant revision comment says: "YEAR(2) is a subject to deprecation since it has ill design."
I'd deprecate it - I agree about "ill design", it has lots of gotchas that are literally impossible to fix. In some cases it seems to work, but it's enough to change the query slightly - and it won't. OTOH it requires less storage, which is a pro. It looks well-defined, that is 0-69 are 2000-2069 and 70-99 are 1970-1999. Though I can't judge the design. Monty likes it. Should I create jira task?
The fundamental design flaw - only the Field itself knows that it's YEAR(2), no item knows it. So, as long as you use YEAR(2) in any expression - it loses its magic powers:
MariaDB [test]> create table t1 (y2 year(2), y4 year(4)); Query OK, 0 rows affected, 1 warning (0.00 sec)
MariaDB [test]> insert t1 values (10, 2010); Query OK, 1 row affected (0.00 sec)
MariaDB [test]> select * from t1; +------+------+ | y2 | y4 | +------+------+ | 10 | 2010 | +------+------+ 1 row in set (0.00 sec)
MariaDB [test]> select y2 = 2010, y4=2010, y2=y4 from t1; +-----------+---------+-------+ | y2 = 2010 | y4=2010 | y2=y4 | +-----------+---------+-------+ | 1 | 1 | 1 | +-----------+---------+-------+ 1 row in set (0.00 sec)
MariaDB [test]> select y2+0 = 2010, y4+0=2010, y2+0=y4+0 from t1; +-------------+-----------+-----------+ | y2+0 = 2010 | y4+0=2010 | y2+0=y4+0 | +-------------+-----------+-----------+ | 0 | 1 | 0 | +-------------+-----------+-----------+ 1 row in set (0.00 sec)
Think also of Item_cache, Item_ref, GROUP BY (with temp tables), subqueries - I really don't know in what cases YEAR(2) works and in what it doesn't.
I see. So what should we do about it? We have to different opinions.
- NO_ENGINE_SUBSTITUTION is default mode in 5.6 now, do we want it be default too?
May be. What do you think? I'd say these days storage engines have way too different semantics. E.g. if user requests FEDERATED but gets MyISAM further queries will return unexpected results.
I believe it is a good idea to make it default too.
Okay. Old idea of SQL_MODE always was that empty set is always the default. I mean, all sql-mode values were selected this way (e.g. NO_ENGINE_SUBSTITUTION vs. ALLOW_ENGINE_SUBSTITUTION).
But I agree, we cannot keep this forever...
Hmm... we could probably keep this idea, change the meaning of empty set to implicitely include NO_ENGIN_SUBSTITUTION and add ALLOW_ENGINE_SUBSTITUTION. As for the new defaults it came to be that they are well documented, so I won't have to dig the code: http://dev.mysql.com/doc/refman/5.6/en/server-default-changes.html Regards, Sergey
Hi, Sergey! On Mar 24, Sergey Vojtovich wrote:
- YEAR(2) is deprecated in 5.6, do we want to deprecate it too? I'd deprecate it - I agree about "ill design", it has lots of gotchas that are literally impossible to fix. In some cases it seems to work, but it's enough to change the query slightly - and it won't. OTOH it requires less storage, which is a pro. It looks well-defined, that is 0-69 are 2000-2069 and 70-99 are 1970-1999. Though I can't judge the design. The fundamental design flaw - only the Field itself knows that it's YEAR(2), no item knows it. So, as long as you use YEAR(2) in any expression - it loses its magic powers:
I see. So what should we do about it? We have to different opinions.
Monty said that the reason for introducing YEAR(2) was to use less storage. I don't know if that's a valid argument today, but anyway. The suggestion was to remove YEAR(2) and introduce YEAR1 (or TINYYEAR, or keep YEAR(2), whatever) type. Which stores the year in one byte, as the old YEAR(2). But Field converts it to 4-digit year on retrieval - in all val_xxx methods. That is, SELECT will show it as 4-digit year, even though it'll be stored only in one byte. If we do it this way, new one-byte year field will have no magic behavior and it'll reliably work in all cases.
- NO_ENGINE_SUBSTITUTION is default mode in 5.6 now, do we want it be default too? I believe it is a good idea to make it default too. Okay. Old idea of SQL_MODE always was that empty set is always the default. I mean, all sql-mode values were selected this way (e.g. NO_ENGINE_SUBSTITUTION vs. ALLOW_ENGINE_SUBSTITUTION).
But I agree, we cannot keep this forever... Hmm... we could probably keep this idea, change the meaning of empty set to implicitely include NO_ENGINE_SUBSTITUTION and add ALLOW_ENGINE_SUBSTITUTION.
Yes, Monty suggested that too. I'm not sure it's a good idea, it basically turns NO_ENGINE_SUBSTITUTION into a no-op. No matter whether it's set or not, engine substitution is not allowed. Which is backward incompatible and will break applications that rely on the engine substitution (e.g. replication with transactional master and non-transactional slaves).
As for the new defaults it came to be that they are well documented, so I won't have to dig the code: http://dev.mysql.com/doc/refman/5.6/en/server-default-changes.html
all changes of buffer sizes, etc are ok. options that affect the behavior... I don't know if we can do it that late, even though it's a compatibility with MySQL 5.6 fix. Regards, Sergei
Hi Sergei, On Mon, Mar 24, 2014 at 10:13:05AM +0100, Sergei Golubchik wrote:
Hi, Sergey!
On Mar 24, Sergey Vojtovich wrote:
- YEAR(2) is deprecated in 5.6, do we want to deprecate it too? I'd deprecate it - I agree about "ill design", it has lots of gotchas that are literally impossible to fix. In some cases it seems to work, but it's enough to change the query slightly - and it won't. OTOH it requires less storage, which is a pro. It looks well-defined, that is 0-69 are 2000-2069 and 70-99 are 1970-1999. Though I can't judge the design. The fundamental design flaw - only the Field itself knows that it's YEAR(2), no item knows it. So, as long as you use YEAR(2) in any expression - it loses its magic powers:
I see. So what should we do about it? We have to different opinions.
Monty said that the reason for introducing YEAR(2) was to use less storage. I don't know if that's a valid argument today, but anyway. The suggestion was to remove YEAR(2) and introduce YEAR1 (or TINYYEAR, or keep YEAR(2), whatever) type. Which stores the year in one byte, as the old YEAR(2). But Field converts it to 4-digit year on retrieval - in all val_xxx methods. That is, SELECT will show it as 4-digit year, even though it'll be stored only in one byte.
If we do it this way, new one-byte year field will have no magic behavior and it'll reliably work in all cases. Ok, then I assume this issue is known and doesn't need extra attention from my side yet.
- NO_ENGINE_SUBSTITUTION is default mode in 5.6 now, do we want it be default too? I believe it is a good idea to make it default too. Okay. Old idea of SQL_MODE always was that empty set is always the default. I mean, all sql-mode values were selected this way (e.g. NO_ENGINE_SUBSTITUTION vs. ALLOW_ENGINE_SUBSTITUTION).
But I agree, we cannot keep this forever... Hmm... we could probably keep this idea, change the meaning of empty set to implicitely include NO_ENGINE_SUBSTITUTION and add ALLOW_ENGINE_SUBSTITUTION.
Yes, Monty suggested that too. I'm not sure it's a good idea, it basically turns NO_ENGINE_SUBSTITUTION into a no-op. No matter whether it's set or not, engine substitution is not allowed. Which is backward incompatible and will break applications that rely on the engine substitution (e.g. replication with transactional master and non-transactional slaves).
I see.
As for the new defaults it came to be that they are well documented, so I won't have to dig the code: http://dev.mysql.com/doc/refman/5.6/en/server-default-changes.html
all changes of buffer sizes, etc are ok. options that affect the behavior... I don't know if we can do it that late, even though it's a compatibility with MySQL 5.6 fix.
Ok, I'll create a task then. Thanks, Sergey
participants (2)
-
Sergei Golubchik -
Sergey Vojtovich