[MDEV-29820] HA_NO_BLOBS for HA_CONNECT needed? Created: 2022-10-18 Updated: 2023-02-01 |
|
| Status: | Open |
| Project: | MariaDB Server |
| Component/s: | Storage Engine - Connect |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Trivial |
| Reporter: | Vincent Milum Jr | Assignee: | Unassigned |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | BLOB, Papercut, TEXT, connect-engine | ||
| Environment: |
FreeBSD 13.1, Ubuntu 22.04 |
||
| 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: |
| Comments |
| Comment by Vincent Milum Jr [ 2022-10-18 ] |
|
I'm not sure why this was created under ColumnStore instead of MDEV..? I wasn't browsing ColumnStore at all. |
| Comment by alexey vorovich (Inactive) [ 2022-10-18 ] |
|
Moved to mdev per comment above |
| Comment by Daniel Black [ 2022-10-19 ] |
|
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. |
| Comment by Vincent Milum Jr [ 2022-10-20 ] |
|
It looks as though LONGTEXT is broken, however, MEDIUMTEXT and TEXT seems to be working just fine still. |
| Comment by Daniel Black [ 2022-10-20 ] |
|
This isn't just a max_allowed_packet size issue on the server being {{connect}}ed to? |
| Comment by Vincent Milum Jr [ 2022-10-20 ] |
|
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. |