Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Cannot Reproduce
    • Affects Version/s: 10.0.15
    • Fix Version/s: N/A
    • Labels:
      None

      Description

      From the error I get in this test case, I suppose that CONNECT doesn't support default values (the error is a bit obscure). However, supporting default values would be useful at least for PROXY tables built on non-CONNECT tables.

      MariaDB [test]> CREATE OR REPLACE TABLE abc (
          -> c INT NOT NULL DEFAULT 1
          -> ) ENGINE = InnoDB;
      Query OK, 0 rows affected (0.48 sec)
      
      MariaDB [test]> CREATE OR REPLACE TABLE conn (
          -> c INT NOT NULL DEFAULT 1
          -> )
          -> ENGINE = CONNECT
          -> TABLE_TYPE = PROXY
          -> TABNAME = abc
          -> OPTION_LIST = 'user=root,password=root';
      Query OK, 0 rows affected (0.09 sec)
      
      MariaDB [test]> INSERT INTO abc VALUES (DEFAULT);
      Query OK, 1 row affected (0.08 sec)
      
      MariaDB [test]> INSERT INTO conn VALUES (DEFAULT);
      ERROR 1296 (HY000): Got error 174 'COLBLK SetBuffer: undefined Access Method' from CONNECT
      

      If I retry the test case without specifying the columns definitions for conn table, I get the following error:

      ERROR 1364 (HY000): Field 'c' doesn't have a default value

        Gliffy Diagrams

          Attachments

            Activity

            Hide
            elenst Elena Stepanova added a comment -

            Works okay for me:

            MariaDB [test]> CREATE OR REPLACE TABLE abc (
                ->   c INT NOT NULL DEFAULT 1
                -> ) ENGINE = InnoDB;
            Query OK, 0 rows affected (0.45 sec)
            
            MariaDB [test]> CREATE OR REPLACE TABLE conn (
                ->   c INT NOT NULL DEFAULT 1
                -> )
                -> ENGINE = CONNECT
                -> TABLE_TYPE = PROXY
                -> TABNAME = abc
                -> OPTION_LIST = 'user=root,password=root';
            Query OK, 0 rows affected (0.02 sec)
            
            MariaDB [test]> 
            MariaDB [test]> INSERT INTO abc VALUES (DEFAULT);
            Query OK, 1 row affected (0.00 sec)
            
            MariaDB [test]> 
            MariaDB [test]> INSERT INTO conn VALUES (DEFAULT);
            Query OK, 1 row affected (0.07 sec)
            
            MariaDB [test]> select @@version;
            +-----------------+
            | @@version       |
            +-----------------+
            | 10.0.15-MariaDB |
            +-----------------+
            1 row in set (0.00 sec)
            

            What am I missing?

            Show
            elenst Elena Stepanova added a comment - Works okay for me: MariaDB [test]> CREATE OR REPLACE TABLE abc ( -> c INT NOT NULL DEFAULT 1 -> ) ENGINE = InnoDB; Query OK, 0 rows affected (0.45 sec) MariaDB [test]> CREATE OR REPLACE TABLE conn ( -> c INT NOT NULL DEFAULT 1 -> ) -> ENGINE = CONNECT -> TABLE_TYPE = PROXY -> TABNAME = abc -> OPTION_LIST = 'user=root,password=root'; Query OK, 0 rows affected (0.02 sec) MariaDB [test]> MariaDB [test]> INSERT INTO abc VALUES (DEFAULT); Query OK, 1 row affected (0.00 sec) MariaDB [test]> MariaDB [test]> INSERT INTO conn VALUES (DEFAULT); Query OK, 1 row affected (0.07 sec) MariaDB [test]> select @@version; +-----------------+ | @@version | +-----------------+ | 10.0.15-MariaDB | +-----------------+ 1 row in set (0.00 sec) What am I missing?
            Hide
            f_razzoli Federico Razzoli added a comment -

            I don't know. In case it matters, I used the tarball on Debian

            Show
            f_razzoli Federico Razzoli added a comment - I don't know. In case it matters, I used the tarball on Debian
            Hide
            elenst Elena Stepanova added a comment -

            Which Debian?

            Also, please attach your SHOW VARIABLES from the session where the failure happens. Thanks.

            Show
            elenst Elena Stepanova added a comment - Which Debian? Also, please attach your SHOW VARIABLES from the session where the failure happens. Thanks.
            Hide
            f_razzoli Federico Razzoli added a comment - - edited

            Debian 7, but I cannot repeat the bug anymore. Sorry.

            (If it happens again, I'll immediately do a SHOW VARIABLES)

            Show
            f_razzoli Federico Razzoli added a comment - - edited Debian 7, but I cannot repeat the bug anymore. Sorry. (If it happens again, I'll immediately do a SHOW VARIABLES)
            Hide
            elenst Elena Stepanova added a comment -

            Okay, I'm closing it for now, we'll re-open it if you have the problem again.

            Show
            elenst Elena Stepanova added a comment - Okay, I'm closing it for now, we'll re-open it if you have the problem again.

              People

              • Assignee:
                Unassigned
                Reporter:
                f_razzoli Federico Razzoli
              • Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                Dates

                • Due:
                  Created:
                  Updated:
                  Resolved: