Active
Project:
Drupal core
Version:
main
Component:
sqlite db driver
Priority:
Major
Category:
Bug report
Assigned:
Unassigned
Issue tags:
Reporter:
Anonymous (not verified)
Created:
28 Feb 2019 at 14:48 UTC
Updated:
25 Jan 2025 at 21:48 UTC
Jump to comment: Most recent
Comments
Comment #1
Anonymous (not verified) commentedlpryszcz created an issue. See original summary.
Comment #2
toamit commentedI agree this is an issue, the db files are getting quite huge.
Comment #3
amateescu commentedAdding a custom collation is a feature of SQLite3 (https://www.sqlite.org/c3ref/create_collation.html) so it's perfectly valid to add our user-space
NOCASE_UTF8collation.Since the SQLite database is generated and maintained by Drupal, you need to run the
VACUUMcommand using Drupal's database layer in order for it to work properly.Comment #4
toamit commentedI suspect the VACCUM command will fail. Any chance you could provide a drush command to accomplish this?
Please don't close the issue until its confirmed that VACUUM command will work when called via Drupal.
Comment #5
toamit commentedComment #6
toamit commented@amateescu the VACUUM command fails when called via drush, please see below
Comment #7
mmoulton commentedThis still seems to be an issue as all of the drush sql:* commands simply execute shell commands using the 'driver' defined in the database config. They do not ever run the `Drupal\Core\Database\Driver\sqlite\Connection::open` command that is bootstrapping sqlite with all of the custom functions and the collation in question here?
While it seems the need to support custom functions and collations is very real, what is the best way to bring the bootstrapping of the driver out to the common management tools used maintain the state of our databases?
Is this a problem with the fundamental way the sql:* drush command work? If so, what can be done to bring continuity between core functionality of all the `Drupal\Core\Database\Driver` implementations through to the common management tools?
Obviously we can make some custom utils to get around this by using the native Connection:open, but that seems to miss the larger problem of a fundamental disconnect between the ubiquitous management tools, such as Drush, and Core.
Comment #8
andypostComment #14
pingwin4egGot this error today trying to manually edit a single field in phpstorm's database view, and trying to update the field in the query console:
So this problem really slows down a development process.
What are the solutions? How did you guys changed that NOCASE_UTF8 on an existing database?
Comment #15
pingwin4egOk, I see that the core adds the collation for purpose:
So how to workaround this in other tools now?
Comment #16
pingwin4egOk, spending a few hours I can't find any workaround to use phpstorm's DB tools with SQLite (except for viewing data in tables as is).
Have to use drush
evcommand like this:drush ev "\Drupal::database()->query('...')"This way drush boots Drupal and executes a query in its context instead of bringing me directly to a DB console.
Comment #17
geek-merlinWhile this is not a general solution, i ported SQLite Vacuum to D8.
Help appreciated with #3283573: Add a drush sqlite:vacuum command.
Comment #20
apolitsin commentedThanks @geek-merlin
```sh
drush php:eval "\Drupal\Core\Database\Database::getConnection('default', NULL)->query('vacuum;');"
```
https://git.drupalcode.org/project/sqlite_vacuum/-/blob/1.0.x/src/Comman...
Not being able to execute `vacuum` really creates a lot of problems.
At the same time the implementation fits in 1 line. Maybe this line should be added somewhere at the sqlite driver level to add such functionality?
Comment #21
wim leersSimply documenting #20 seems sufficient? 😊
(Many thanks, @apolitsin! 🙏)