Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-3998

Cassandra SE: Cryptic error message on SELECT from a badly formed table

    XMLWordPrintable

Details

    • Bug
    • Status: Closed (View Workflow)
    • Trivial
    • Resolution: Won't Fix
    • 10.0.1
    • 10.0.11
    • None

    Description

      I create a valid column family:

      cqlsh:manual_test> create columnfamily cf1 ( rowkey int primary key, a int );

      Then I create a Cassandra table which only has a column for rowkey, but not for `a`. I expected it to fail, but it works all right:

      create table t1 (rowkey int primary key) engine=cassandra keyspace='manual_test' column_family='cf1';
      # Query OK, 0 rows affected (0.12 sec)

      Then I insert into the table. I thought now it would fail for sure, but it worked too:

      insert into t1 values (1);
      # Query OK, 1 row affected (0.00 sec)

      Then I selected from the table. Since all the above worked, I thought it would work also, but it didn't:

      select * from t1;
      # ERROR 1928 (HY000): Internal error: 'Default TException. [predicate column_names and slice_range may not both be null]'

      The error message is anything but clear, I can only guess what it's about because I made the mess myself. Since the table is basically non-functional, maybe it makes sense to forbid creating it in the fist place.

      revision-id: psergey@askmonty.org-20121224043622-xn8g8y3vhtu1lb3w
      revno: 3459
      branch: 10.0-base-cassandra

      Attachments

        Issue Links

          Activity

            People

              psergei Sergei Petrunia
              elenst Elena Stepanova
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Git Integration

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