Problem/Motivation
Trying to get automated tests to work in SQlite that work fine when using MySQL connection.
Steps to reproduce
1. Apply patch from https://www.drupal.org/project/dbal/issues/3185995#comment-13923913
2. Set up phpunit to use sqlite.
3. Run phpunit , eg:
phpunit web/modules/contrib/dbal/tests/src/Kernel/DbalConnectionKernelTest.php
Proposed resolution
Update the dbal module to work with sqlite.
This is related to
https://www.drupal.org/project/dbal/issues/3185995
Issue fork dbal-3186378
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
finn lewisHere's the error:
Comment #3
larowlanPlease see the known issues on the project page - https://www.drupal.org/project/dbal is this the same thing?
Comment #4
finn lewisHi larowlan,
Thanks for the rapid response!
I'm not sure if this is the same thing, but it might be related.
The test in question is being run in isolation.
When the SIMPLETEST_DB variables is set to use mysql, it works fine:
When the SIMPLETEST_DB variables is set to use sqlite, it fails:
In neither case are we setting a specific table prefix in the connection string.
It looks to me like phpunit creates its db prefix when setting up the test.
Just to confirm, this is the test:
https://git.drupalcode.org/project/dbal/-/blob/8.x-1.x/tests/src/Kernel/...
Comment #5
larowlanThe main issue is that all the Drupal SQL drivers use a special query syntax, where the table names are wrapped in {} and then this is replaced with the prefixed name at query execution time.
There is no such concept (that I know of) in dbal.
In this scenario, are there any tables in the sqlite file?
Comment #6
finn lewisWith MySQL I see that the two tables are created, with the prefix:
test84518174semaphore
test84518174config
Which then allows the dbal connection to insert the row to test84518174semaphore.
With SQLite
Pausing the debugger before the insert is attempted at
https://git.drupalcode.org/project/dbal/-/blob/8.x-1.x/tests/src/Kernel/...
I see the following files created:
-rw-r--r-- 1 finn finn 4096 Dec 3 22:24 testfile.sqlite
-rw-r--r-- 1 finn finn 32768 Dec 3 22:25 testfile.sqlite-shm
-rw-r--r-- 1 finn finn 28672 Dec 3 22:25 testfile.sqlite-test81396060
Looking inside those files, the testfile.sqlite-shm file does have sql that suggests the creation of the same tables (long with lots of other crazy characters):
Allowing the test to finsh and fail, leaves just the one file
-rw-r--r-- 1 finn finn 4096 Dec 3 22:24 testfile.sqlite
So it seems that sqlite creates a number of files as it does it's thing, but perhaps the dbal connection is still looking at the original file name.
Comment #7
finn lewisComment #8
finn lewisI should also have been clear that I have applied the patch from https://www.drupal.org/project/dbal/issues/3185995#comment-13923913
I've updated the summary to clarify that as a step to reproduce.
I should probably have just extended that issue to be honest, sorry.
Is the issue something around not providing the dbal connection the right information about the sqlite connection?
What is the correct array of options to pass to this for an sqlite connection?
https://git.drupalcode.org/project/dbal/-/blob/8.x-1.x/src/ConnectionFac...
Comment #11
ekes commentedI've made a similar comment in the commit message on that branch, but I'll pop it here too.
Drupal handles prefixes for SQLite quite differently from MySQL. SQLite has a concept where you have attachment databases to the current connection. These are accessed via `attachment_name.table_name`, with a period, much as in MySQL you'd specify a database. When you request the ::getFullQualifiedTableName() MySQL will return `prefix_stringtable_name` where as SQLite will return 'prefix_string.table_name' so it is actually using one of these attachment databases. When using DBAL you can access MySQL prefixed tables if you take the responsibility to access the correct table name by just adding the prefix. When using DBAL with SQLite the attachment databases need to be added first.
Comment #13
larowlan❤️ thank you, I had no idea about any of these concepts.
Rolling a new release with this change included.
Comment #14
larowlanComment #15
finn lewisAmazing, thanks @ekes and thanks @larowlan for rolling a new release so quickly.
Comment #16
larowlanNo worries, commits that sit in HEAD without a release for a long time is a pet peeve, so I favour release early, release often
You should see entity_hierarchy's list of releases