NightJar commented 6 years ago

I've tried installing this to try and run tests at a speed of more than one per 10 minutes or so. However, configuration is proving... troublesome.

Steps to reproduce: 1) install module 2) .env (as below) 3) vendor/bin/sake dev/build

Fatal error: Attempted to connect to non-existing database "SS_testtest" in /home/user/projects/testtest/vendor/silverstripe/sqlite3/code/SQLite3Database.php on line 247

The env file contains:

SS_DATABASE_CLASS=SQLite3Database
SS_SQLITE_DATABASE_PATH=/home/user/projects
SS_DATABASE_CHOOSE_NAME=1

and the usual other accompanyments.

It's worth noting here that NOT setting a database name causes an error on CoreKernel::boot (even though this adaptor doesn't require it), and choosing the name shouldn't matter.

The user has write access to the folder in question (being that I'm running a via cli, it is my user in my home dir). The database file is created.

So what's happening? Copious var_dumping tells me that: 1) The configuration appears to be perfectly fine. https://github.com/silverstripe/silverstripe-sqlite3/blob/2/_config/connectors.yml#L11 2) The schema manager is set and configured by injector: https://github.com/silverstripe/silverstripe-framework/blob/4.0/src/ORM/Connect/Database.php#L92 3) The connection details are set and stored correctly. The data base is created. 4) The entirety of all of the above is simply dropped and replaced by new UNCONFIGURED replacements. That is to say, as if connect is never called. 5) With the lack of setting path correctly at any point on this new object, selectDatabase then proceeds to try and test /home/user/projects/testtest/public/assets/.sqlitedb for ... well, existing. This file will only ever be set if we did not choose a database path or name. We cannot not choose a database name, the core will refuse to boot. So it seems to me this is always wrong.

But, why?

This might interest you, @tractorcow

Aforementioned copious var_dumping has seen:

object(SilverStripe\FullTextSearch\Search\Captures\SearchManipulateCapture_SQLite3Database)#547 (7) { is my Database during the call to connect
By the time we get to selectDatabase the object has become: object(AuditLoggerManipulateCapture_SilverStripe_FullTextSearch_Search_Captures_SearchManipulateCapture_SQLite3Database)#624 (8) {

This issue may or may not be caused by FullTextSearch proxying my connector, but then it also may be. This part I've not looked into.

tractorcow commented 6 years ago

Have you tested this with only fulltextsearch proxy or also https://github.com/tractorcow/silverstripe-proxy-db?

NightJar commented 6 years ago

I have not had any chance to test any further yet. My first port of call will be to test without fulltextsearch installed (ie. without any db proxy shimming in place), to see if the problem persists itself.

If it does, I'll try to fix it.

If it doesn't, I'll try to see what happens if I test with your proxy standardisation Proof of Concept :)

NightJar commented 6 years ago

Confirmed. It's because of Database Proxies. After removing FulltextSearch and Auditor, the database builds; resulting in a healthy 2M .sqlite file. Something to do with the way the connection is cloned I guess.

NightJar commented 6 years ago

Also confirmed; recent swtich in both modules to https://github.com/tractorcow/silverstripe-proxy-db resolves said sudden deaths.

tractorcow commented 6 years ago

Yay.

silverstripe / silverstripe-sqlite3

Database proxies may cause extreme failure #41

But, why?