feat: support urlbased config for sqlite

[xujihui1985]

Does your PR solve an issue?
This PR introduces support for configuring journal_mode and busy_timeout via the SQLite database URL, improving ergonomics and aligning with behavior in other ecosystems.

Currently, libraries like SeaORM do not expose journal_mode and busy_timeout through DatabaseConfig, which requires users to manually run PRAGMA commands after establishing a connection. This adds complexity and boilerplate. By allowing these settings to be specified in the URL itself, usage becomes much simpler and declarative.

This feature mirrors existing functionality in other SQLite libraries such as the Go SQLite driver mattn/go-sqlite3, which supports these parameters in the DSN.

Example usage:

sqlite://app.db?_journal_mode=WAL&_busy_timeout=5000

Is this a breaking change?
No, this is not a breaking change. Existing URLs will continue to work as before, and the new configuration options are optional and additive.

Additional context
This change improves developer experience by eliminating the need to execute manual PRAGMA statements by using sea-orm and allows consistent configuration via connection string.

Unit and/or integration tests have been added to verify that journal_mode and busy_timeout are correctly parsed and applied from the URL configuration.

[abonander]

I'm not overly comfortable with making the journal mode a URL parameter. The application should be aware of what journal mode it's using because different modes can have very different semantics regarding locking and durability.

For example, setting the journal mode to OFF turns any ROLLBACK statement issued by the application into "undefined" behavior (probably not what we would think of as "undefined behavior" but likely just as bad). WAL mode is a persistent setting on the database that requires a file-wide lock to change in and out of, which can trigger a SQLITE_BUSY error on concurrent connection attempts--again, something the application should probably be aware of.

busy_timeout is also arguably something the application should be aware of, in the case that it's meant to synchronize with other timeouts. Setting it longer or shorter could change an application's behavior in unexpected ways. For example, if a query is wrapped in a timeout() call and the calling code is designed to recover from that but not a SQLITE_BUSY error, setting the busy timeout shorter would make the application misbehave.

IMHO, if these parameters aren't exposed in SeaORM's API, that's a SeaORM issue. The connection URL is not meant to be a catch-all for configuration.

[xujihui1985]

@abonander Thanks for your reply. I totally agree that the application should be aware of these settings. In real-world use cases, PRAGMAs like journal_mode should be set when the database is first opened—it doesn’t make sense to open the database with one mode and then operate with another.

My understanding is that setting it in the URL acts more like a default configuration—similar to a shortcut for calling the journal_mode() function. It gives the application an easier way to set the initial configuration and also makes it explicit that the database is opened in WAL mode.

Apologies for bringing up SeaORM as a bad example. I really appreciate your insights and thoughtful explanation.

[abonander]

The problem is that the application could just decide that the default is acceptable and not explicitly set journal_mode. I can imagine a lot of them doing that. Your SeaORM application, for example, would be forced to do that... unless SeaORM was changed to expose the option, which would make this change redundant.

I don't like that this makes it possible for the user to (potentially) significantly change the behavior of the application (or make it possible to invoke undefined behavior and corrupt the database file) just by changing a single URL parameter. There is SQLITE_DBCONFIG_DEFENSIVE that disables journal_mode=OFF but that's not currently exposed, either.

I also don't find it sufficiently compelling that a driver in a different language decided to expose this. Looking through their issue tracker, they've had some problems caused by the exact implementation of it and how it can go wrong when used inconsistently: mattn/go-sqlite3#607

[xujihui1985]

@abonander ok, I understand what you concerned. Again, thanks for your time to explain me