Details

    • Task
    • Status: Open (View Workflow)
    • Major
    • Resolution: Unresolved
    • None
    • OTHER
    • None

    Description

      Currently we have two flags:

      • STRICT_TRANS_TABLES
      • STRICT_ALL_TABLES

      These flags were originally added to control how to treat warnings that happen on updating table fields for transactional and non-transactional tables.

      Gradually these flags spread all around the code to change the server behavior in contexts not directly related to tables, such as:

      • SP variables, SP routine parameters, function return values
      • Built-in SQL functions (e.g. badly formed strings)
      • Too long comments
      • Too long messages in SIGNAL
      • Duplicate values in ENUM/SET
      • Automatic VARCHAR -> BLOB conversion

      During recent discussions we agreed (bar, elenst, serg) that STRICT_XXX_TABLES should not affect anything when no tables are involved.

      To address that we restore the original meaning of these flags:

      • STRICT_TRANS_TABLES applies to all cases where a statement can be cleanly aborted, restoring the data as it was before the statement started executing
      • STRICT_ALL_TABLES applies to all cases, even when it'll leave tables partially updated

      We might rename flags to better match the intended semantics.

      original proposal:

      To address this, we'll introduce a new STRICT_XXX flag that will control server behavior when no tables are involved.

      The exact flags name is a subject to discussion.

      Attachments

        Issue Links

          Activity

            Then it would be a move in an opposite direction to what the description says, and in orthogonal direction to a sanity vector: we now have STRICT_xx_TABLES flags which are sometimes not about tables and not quite about "xx", after the change we'll have the flags which are indeed about "xx", but not about tables at all.

            elenst Elena Stepanova added a comment - Then it would be a move in an opposite direction to what the description says, and in orthogonal direction to a sanity vector: we now have STRICT_xx_TABLES flags which are sometimes not about tables and not quite about "xx", after the change we'll have the flags which are indeed about "xx", but not about tables at all .

            Perhaps rename and keep the old names for backward compatibility?

            bar Alexander Barkov added a comment - Perhaps rename and keep the old names for backward compatibility?

            elenst, I think it'll be mostly about tables. STRICT_TRANS_TABLES will make statements "strict" if only transactional tables but none of the non-transactional tables were modified. STRICT_ALL_TABLES will make statements "strict" even if non-transactional tables were modified.

            This goes back to the original intention of those sql modes, STRICT_TRANS_TABLES aborts on warnings only when the statement can be completely rolled back, and STRICT_ALL_TABLES aborts on warnings even if the statement cannot be completely rolled back.

            serg Sergei Golubchik added a comment - elenst , I think it'll be mostly about tables. STRICT_TRANS_TABLES will make statements "strict" if only transactional tables but none of the non-transactional tables were modified. STRICT_ALL_TABLES will make statements "strict" even if non-transactional tables were modified. This goes back to the original intention of those sql modes, STRICT_TRANS_TABLES aborts on warnings only when the statement can be completely rolled back, and STRICT_ALL_TABLES aborts on warnings even if the statement cannot be completely rolled back.

            serg, still, the whole point of the item, according to the description, is "STRICT_XXX_TABLES should not affect anything when no tables are involved". And your suggestion for both flags is "always in any situation, no matter whether tables are involved or not <...>". I don't see any correlation between the two. Semantically nothing will improve.

            elenst Elena Stepanova added a comment - serg , still, the whole point of the item, according to the description, is "STRICT_XXX_TABLES should not affect anything when no tables are involved". And your suggestion for both flags is "always in any situation, no matter whether tables are involved or not <...>". I don't see any correlation between the two. Semantically nothing will improve.
            serg Sergei Golubchik added a comment - - edited

            Yes, we'll have to clarify the documentation to go back to the original intention of those sql modes. It seems now the semantics became too literal and, perhaps, rather meaningless.

            serg Sergei Golubchik added a comment - - edited Yes, we'll have to clarify the documentation to go back to the original intention of those sql modes. It seems now the semantics became too literal and, perhaps, rather meaningless.

            People

              serg Sergei Golubchik
              bar Alexander Barkov
              Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

                Created:
                Updated:

                Git Integration

                  Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.