Improve sql-storage tile writing to allow the sql-driver to split network-packages

[SheepReaper]

I use pebblehost. They provide MySQL databases, but the server has max_allowed_packet set to 16777216 (16M), and we cannot raise it. Bluemap tries to send packets of 25 M. Short of modifying the JDBC driver directly, I'm unsure how to set the client-side limit. I want Bluemap to consider exposing it in its config if there is one. Currently, I cannot use SQL storage on my host due to this constraint. Not the end of the world, though. If it's impossible, I don't know the limitations of the JDBC driver (I'm using a forge/neoforge mod that wraps the vanilla MySQL driver jar).

[TBlueF]

BlueMap already exposes the entire jdbc-config by allowing you to set both the full jdbc-string (connection-url) and the properties (connection-properties) that it passes to the jdbc-driver.

The only file - unless you turned compression off - bluemap saves to the db that could theoretically somehow reach sizes of 25M is the textures.json containing all the texture-data. So if you have a very high-resolution resourcepack or a ton of mods that add new textures, then this file gets bigger.

I read of ways to split a single blob INSERT/REPLACE into multiple packets when sending it to the server, i will take a look if thats possible to implement.

Other then that, right now your only options are to increase that value on the server, or somehow reduce the texture-atlas size, by removing the high-resolution resourcepack or loading less modded textures with bluemap.

[SheepReaper]

It's just the ATM10 mod pack, no modifications besides adding bluemap. And I just let bluemap alone with its default settings except for SQL obviously. Did I miss a setting to exclude specific resource packs from blue map's discovery? Maybe store the atlas in per-pack shards and assemble it at runtime?

[TBlueF]

I did some further testing and to me it seems like there is no good way to tell the jdbc driver to split the file into multiple packets for uploading.
I am open for suggestions, but for now i'll assume it's not feasible and the only way is to either increase the servers packet-size or switch to a different storage that supports larger files.

I do want to look into storing texture-data and marker-data (which can both scale into huge files in these edge-cases) in a different way in the future, so that it's not needed to cram them all into one big file.
That could then improve this as well. However that's a different topic, so i will close this issue for now.