hepabolu / mytap

MySQL Unit Testing Suite

Home Page:http://hepabolu.github.com/mytap/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

MyTAP test functions should be declared deterministic, where possible

Ovid opened this issue · comments

commented

When we tried to use MyTAP at work, it seemed to be fine on some dev servers, but for sandboxes, it was failing with the following error:

Deploying changes to tap
  + mytap_schema @v0.03 .. ERROR 1418 (HY000) at line 28 in file: '/tmp/o6m_IzqHJP': This function has none of DETERMINISTIC, NO SQL, or READS SQL DATA in its declaration and binary logging is enabled (you *might* want to use the less safe log_bin_trust_function_creators variable)

In MySQL, if you have binary logging enabled, functions which are not deterministic might cause issues in data corruption in replication or data restoration. Here is the relevant section from the MySQL docs:

When you create a stored function, you must declare either that it is deterministic or that it does not modify data. Otherwise, it may be unsafe for data recovery or replication.

By default, for a CREATE FUNCTION statement to be accepted, at least one of DETERMINISTIC, NO SQL, or READS SQL DATA must be specified explicitly. Otherwise an error occurs:

ERROR 1418 (HY000): This function has none of DETERMINISTIC, NO SQL,
or READS SQL DATA in its declaration and binary logging is enabled
(you might want to use the less safe log_bin_trust_function_creators
variable)

This function is deterministic (and does not modify data), so it is safe:

CREATE FUNCTION f1(i INT)
RETURNS INT
DETERMINISTIC
READS SQL DATA
BEGIN
  RETURN i;
END;

This function uses UUID(), which is not deterministic, so the function also is not deterministic and is not safe:

CREATE FUNCTION f2()
RETURNS CHAR(36) CHARACTER SET utf8
BEGIN
  RETURN UUID();
END;

Would you submit a pull request, please?

Better yet, how would you like co-maint? 👍

commented

Hmm, now that I'm reading through the code, I see that many functions aren't deterministic. Thus, I am not sure how this can work with binary logging. Given that it's all supposed to driven through a transaction that's rolled back, it should be safe, but MySQL can't know that.

Check out this pull request: #6

Given the age of this issue and the fact that the mentioned pull request has now been merged, I'll close this issue.