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

CONNECT JSON table type only returns 10 rows

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Not a Bug
    • Affects Version/s: 10.0.16
    • Fix Version/s: N/A
    • Component/s: Documentation
    • Labels:
      None

      Description

      { "items": [
      { "id": 0, "value": "a" },
      { "id": 1, "value": "b" },
      { "id": 2, "value": "c" },
      { "id": 3, "value": "d" },
      { "id": 5, "value": "e" },
      { "id": 6, "value": "f" },
      { "id": 7, "value": "g" },
      { "id": 8, "value": "h" },
      { "id": 9, "value": "i" },
      { "id": 10, "value": "j" },
      { "id": 11, "value": "k" },
      { "id": 12, "value": "l" },
      { "id": 13, "value": "m" }
      ] }
      
      mariadb 10.0.16-MariaDB-log (root) [test]> create table json ( id int field_format='items:[x]:id', value char(1) field_format='items:[x]:value' ) engine=connect, table_type=json, file_name='test.json';
      Query OK, 0 rows affected (0.01 sec)
      
      mariadb 10.0.16-MariaDB-log (root) [test]> select * from json;
      +------+-------+
      | id   | value |
      +------+-------+
      |    0 | a     |
      |    1 | b     |
      |    2 | c     |
      |    3 | d     |
      |    5 | e     |
      |    6 | f     |
      |    7 | g     |
      |    8 | h     |
      |    9 | i     |
      |   10 | j     |
      +------+-------+
      10 rows in set (0.00 sec)
      

        Gliffy Diagrams

          Attachments

            Activity

            Hide
            bertrandop Olivier Bertrand added a comment - - edited

            It is not a bug, however the documenation is missing an important item. When an array is expanded, or its values concatenated or calculated, the number of used array items is limited to the value of the LIMIT option whose default value is 10 (as for the XML table type row expanding)
            I recognize that this seems too drastic in your example because the expansion here represents the total number of rows of the table. It was done initially to restrict the size of, for instance, the concatenated names of authors of a book. I shall see if this is to be suppressed or modulated differently.
            Your problem could be fixed by adding to the create table OPTION_LIST='Limit=n' n being greater than the size of your table.
            However, the true fix is here to define the whole table as the array (instead of expanding it):

            create table json (id int, value char(1)) engine=connect, table_type=json, file_name='test.json', option_list='object=items';
            

            Here the limit does not apply.

            Show
            bertrandop Olivier Bertrand added a comment - - edited It is not a bug, however the documenation is missing an important item. When an array is expanded, or its values concatenated or calculated, the number of used array items is limited to the value of the LIMIT option whose default value is 10 (as for the XML table type row expanding) I recognize that this seems too drastic in your example because the expansion here represents the total number of rows of the table. It was done initially to restrict the size of, for instance, the concatenated names of authors of a book. I shall see if this is to be suppressed or modulated differently. Your problem could be fixed by adding to the create table OPTION_LIST='Limit= n ' n being greater than the size of your table. However, the true fix is here to define the whole table as the array (instead of expanding it): create table json (id int , value char (1)) engine=connect, table_type=json, file_name='test.json', option_list='object=items'; Here the limit does not apply.
            Hide
            kolbe Kolbe Kegel added a comment -

            Olivier, great! Thanks for the reply

            There's surely plenty of room for improved documentation about this stuff. And some more examples. I'll turn this one into a blog post at some point I think.

            Show
            kolbe Kolbe Kegel added a comment - Olivier, great! Thanks for the reply There's surely plenty of room for improved documentation about this stuff. And some more examples. I'll turn this one into a blog post at some point I think.

              People

              • Assignee:
                bertrandop Olivier Bertrand
                Reporter:
                kolbe Kolbe Kegel
              • Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:

                  Time Tracking

                  Estimated:
                  Original Estimate - Not Specified
                  Not Specified
                  Remaining:
                  Remaining Estimate - 0 minutes
                  0m
                  Logged:
                  Time Spent - 1 hour
                  1h