Closed NightJar closed 6 years ago
Have you tested this with only fulltextsearch proxy or also https://github.com/tractorcow/silverstripe-proxy-db?
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 :)
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.
Also confirmed; recent swtich in both modules to https://github.com/tractorcow/silverstripe-proxy-db resolves said sudden deaths.
Yay.
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
The env file contains:
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_dump
ing 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 ifconnect
is never called. 5) With the lack of settingpath
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_dump
ing has seen:object(SilverStripe\FullTextSearch\Search\Captures\SearchManipulateCapture_SQLite3Database)#547 (7) {
is myDatabase
during the call toconnect
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.