Details

    Description

      Is there a particular reason why the CONNECT storage engine defines the HA_NO_BLOBS parameter?

      In my particular use case, I just need to federate "some" data (possibly terabytes) from another location, and that location contains some JSON blobs. This is in a read-only context.

      Removing the HA_NO_BLOBS flag allows me to define columns as TEXT to pull in the JSON data from the remote MySQL/MariaDB servers. This appears to be working just fine.

      My particular use case is a read-only use case and only using the federated side of CONNECT. Is it possible this flag is set due to write workloads, or other data sources like CSV files that the engine supports? If so, I think this should be gated some other way so at least federated reading would be possible.

      Otherwise, we normally would get the following error message:
      ERROR 42000: Storage engine CONNECT doesn't support BLOB/TEXT columns

      Attachments

        Activity

          I'm not sure why this was created under ColumnStore instead of MDEV..? I wasn't browsing ColumnStore at all.

          darkain Vincent Milum Jr added a comment - I'm not sure why this was created under ColumnStore instead of MDEV..? I wasn't browsing ColumnStore at all.

          Moved to mdev per comment above

          alexey.vorovich alexey vorovich (Inactive) added a comment - Moved to mdev per comment above
          danblack Daniel Black added a comment - - edited

          I looked it up and it was added with commit without explanation. The commit seems to show it wasn't handling BLOB/TEXT on dbf connections (but I thought the original error of "HY000: Unsupported type for column a" was perfectly ok).

          Happy to take a PR removing the HA_NO_BLOBS and reverting the error in the DBF test against any version tested.

          danblack Daniel Black added a comment - - edited I looked it up and it was added with commit without explanation. The commit seems to show it wasn't handling BLOB/TEXT on dbf connections (but I thought the original error of "HY000: Unsupported type for column a" was perfectly ok). Happy to take a PR removing the HA_NO_BLOBS and reverting the error in the DBF test against any version tested.
          darkain Vincent Milum Jr added a comment - - edited

          It looks as though LONGTEXT is broken, however, MEDIUMTEXT and TEXT seems to be working just fine still.

          darkain Vincent Milum Jr added a comment - - edited It looks as though LONGTEXT is broken, however, MEDIUMTEXT and TEXT seems to be working just fine still.
          danblack Daniel Black added a comment -

          This isn't just a max_allowed_packet size issue on the server being {{connect}}ed to?

          danblack Daniel Black added a comment - This isn't just a max_allowed_packet size issue on the server being {{connect}}ed to?

          I don't think so, considering the individual rows are only ~20KB in size. The source table was the same when I tested TINYTEXT, TEXT, MEDIUMTEXT, and LONGTEXT on the CONNECT table. The first truncated data, as expected. The next two worked as expected. LONGTEXT produced empty data entirely, plus was throwing data errors with some queries.

          darkain Vincent Milum Jr added a comment - I don't think so, considering the individual rows are only ~20KB in size. The source table was the same when I tested TINYTEXT, TEXT, MEDIUMTEXT, and LONGTEXT on the CONNECT table. The first truncated data, as expected. The next two worked as expected. LONGTEXT produced empty data entirely, plus was throwing data errors with some queries.

          People

            Unassigned Unassigned
            darkain Vincent Milum Jr
            Votes:
            0 Vote for this issue
            Watchers:
            4 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.