Add 3.37 SQLite database driver

[yosifkit]

Drupal 11 core requires SQLite 3.45, but Bullseye and Bookworm do not have that, so they need this alternative driver. The alternative SQLite database driver only requires SQLite 3.37. It can be chosen during the site setup wizard.

Note that the alternative adapter is version 1.0@alpha and is provided by a Drupal developer (https://www.drupal.org/project/sqlite337). Being called an "alpha" release gives me pause, so please test that it works for your use cases (and maybe only use it for dev and not prod). It might not see updates, but we are definitely happy to bump the install line when there are.

Fixes #264

[tianon]

Agreed, I don't love this, but it seems ~sane.

Maybe we leave it open for a little bit in case there are some strong objections we should consider?

[tianon]

@effulgentsia apologies for the ping, but we'd really love/appreciate your opinion on our including your sqlite337 in the applicable images of https://hub.docker.com/_/drupal (11+, Debian Bookworm/Bullseye) if that's something you're willing to think about and share ❤️

(of course, no hard feelings at all if that's not something you're interested in or willing to do! 🙇)

[mstenta]

Personally I think this solution isn't worth it, for a few reasons:

1. The module is "alpha" and only 4 sites are reported to be using it. It feels risky to implicitly declare support for it by including it in this image. But I should say that I haven't reviewed it, and maybe it's very simple.
2. If someone does install Drupal with the "SQLite3.37 or higher" option, what does that actually "do" in the installation? What happens when Trixie is released and that module is no longer necessary? What is the transition procedure? Maybe that's documented somewhere but if we include it here we should also document how to "undo" it in the future. It looks like it requires a change to settings.php, so maybe it's just a matter of removing that change? I would be curious if any database records are touched. Probably not?
3. The number of downstream users of this image who are installing on SQLite3 is probably very small, and furthermore the number of downstream users who are using the Drupal codebase built from the composer.json included with this image is probably even fewer. I would assume most downstream users are building from their own composer.json (Drupal installations generally need additional modules for their specific requirements). If they need it, they can choose to install this module themselves.

If we really want to support SQLite3 (until Trixie) is released, it's probably a lot easier to just backport the SQLite3 version from Trixie. That's what we did in the farmOS distribution. See: #264 (comment)

All our SQLite3 tests are passing with that minor addition to our Dockerfile (which extends from this image).

Just my 2 cents. :-)

[tianon]

The transition story is a really great point, and the primary thing that's convinced me to about-face on my opinion here -- if we leave installing https://www.drupal.org/project/sqlite337 up to users, then the transition story is also theirs to own (which is much saner/safer than us trying to automatically fix things for them somehow). 👍

[effulgentsia]

The module is "alpha" and only 4 sites are reported to be using it

I can tag a stable release of it. It's been at alpha for almost a year and no issues have been reported against it in all that time, though fair point that it's getting little usage so a lack of reported issues doesn't necessarily mean lack of latent problems.

maybe it's very simple

It is indeed very simple. At this point in time, all it does is subclass Drupal core's SQLite driver and overrides the SQLITE_MINIMUM_VERSION constant. This works because Drupal core's SQLite driver at present doesn't use any SQLite syntax from 3.38 or later. That's true even for Drupal 11.2 which just came out. However, it's possible that Drupal 11.3 will use newer SQLite syntax (such as JSONB functions), at which time I'll need to add polyfills to the sqlite337 module.

The number of downstream users of this image who are installing on SQLite3 is probably very small

I think this is the key judgment call for the maintainer(s) of this Docker image to make. Is it worth adding stuff to the image that people using the image with MySQL or PostgreSQL don't need? I don't know the answer to that.

it's probably a lot easier to just backport the SQLite3 version from Trixie

If this is in fact easy, I'd agree that this is preferable. It would mean that whenever Drupal does start using jsonb functions in SQLite (or any other modern SQLite syntax), that these would work "properly" rather than polyfilled.

[yosifkit]

Thank you all for the feedback. I agree that this might not be desired for all users and is an easy addition for those who need it. I would not advocate adding Trixie's library, but once Debian Trixie is released "soon", we'll definitely have an image based on it.