New driver fixes from manual testing

[JanJakes]

List of discovered issues:

• Data types from _mysql_data_types_cache are sometimes not correctly fetched, as they can be saved in multiple formates (lowercase, uppercase, with or without backticks).
• MySQL applies type casting when saving data in non-strict mode, resulting in things like empty string being saved as 0 for an integer, 0000-00-00 00:00:00 for a date, etc.
• Functional defaults are incorrectly applied in non-strict mode (DEFAULT CURRENT_TIMESTAMP saves a 'CURRENT_TIMESTAMP' string rather than the correct value).
• MySQL BINARY type is saved as INTEGER, but it's actually a binary string, and BLOB would be more suitable.
• MySQL supports date and time components without a zero padding, but that doesn't work with date and time functions in SQLite. (E.g.: 2025-3-7 9:5:2 is a valid datetime/timestamp value in MySQL, but SQLite requires it to be 2025-03-07 09:05:02.)
• In multi-process environments (php-fpm), concurrent writes can cause "SQLSTATE[HY000]: General error: 5 database is locked" (SQLITE_BUSY).

[adamziel]

I'd add this excerpt:

Transactions can be DEFERRED, IMMEDIATE, or EXCLUSIVE. The default transaction behavior is DEFERRED.

DEFERRED means that the transaction does not actually start until the database is first accessed.

IMMEDIATE causes the database connection to start a new write immediately, without waiting for a write statement. The BEGIN IMMEDIATE might fail with SQLITE_BUSY if another write transaction is already active on another database connection.

It also makes me question why BEGIN IMMEDIATE works – this passage suggests it should not. Is there any way we can add a deterministic unit test?

[JanJakes]

@adamziel I added the docs: 31c319c

It also makes me question why BEGIN IMMEDIATE works – this passage suggests it should not.

I think it works because even though upgrading a read transaction to a write transaction fails immediately when another write is in progress, the BEGIN IMMEDIATE statement can honor the busy_timeout, as there is no need to restart a full transaction.

Is there any way we can add a deterministic unit test?

I can give it a shot. Probably not so easy to do in PHP.

[adamziel]

Thanks! Maybe starting two connections in a single thread would suffice? If we can avoid synchronizing multiple processes it may be pretty easy

[JanJakes]

@adamziel I don't have any async query APIs at hand, so I'm quite limited in what I can do. I can create a locked state, and I could measure that it applies a timeout, but that's about it:

$driver1->query('CREATE TABLE t (id INT)');
$driver1->query('BEGIN');
$driver2->query('INSERT INTO t (id) VALUES (2)'); // this waits for $driver1 to finish, and timeouts
$driver1->query('COMMIT'); // but we never get to this, because all the APIs are sync

[adamziel]

Ah, I see what you mean. Would this help? https://github.com/clue/reactphp-sqlite

[JanJakes]

@adamziel I think so, yeah, should we add it for this test?

[adamziel]

yeah

[JanJakes]

@adamziel Ah, but installing that package will actually not give the SQLite driver the async APIs (we're using PDO), so I'm afraid it's not an easy solution either. I had some luck with pcntl_fork, maybe I can try to finish that.

[adamziel]

Symfony\Process is pretty neat FWIW. I use it in the new Blueprint runner. But it's not quite forks so pcntl might be for the best

[adamziel]

I only have one note that may or may not be blocking. Really good work here, thank you 🙌