* FIX PHP 8.1 support in MySQLiConnector::query errors
The default error reporting mode in PHP 8.1 has changed from using
errors reported on the connection handle to throwing
mysqli_sql_exception. query() makes no allowance for this, and
functions up the call stack expect to catch
Silverstripe\ORM\Connect\DatabaseException instead - resulting in the
MySQLi exception going all the way up to halt the system.
We can use a try, catch, and finally to retain backwards compatibility,
no matter which setting (e.g. PHP version default) someone has enabled.
* Move MySQLConnector test skip call into setUp()
As review feedback; marking the test as skipped in a private function
obfuscated where the call was happening and made it harder to skimread
the tests. Moving this into a setUp function makes it obvious the check
is run before each test case, and skipped if necessary.
* NEW DatabaselessKernel to support operation without DB
This is required for GraphQL code generation in CI (without a working runtime database/webserver environment).
Context: https://github.com/silverstripe/silverstripe-graphql/issues/388
* New --no-database option for sake
* Refactor to abstract class
* Apply feedback peer review
Co-authored-by: Aaron Carlino <unclecheese@leftandmain.com>
Co-authored-by: Maxime Rainville <maxime@silverstripe.com>
The Postgres implementation was always faulty,
but the database exception was swallowed until
See https://github.com/silverstripe/silverstripe-framework/pull/9456.
Now that the the exception is only swallowed the first time,
the second recurrence will cause failing test execution.
This is a bit of an awkward fix, but the indirection "through" DataObject doesn't allow for anything else without changing public API surface.
The logic goes from TempDatabase to DBSchemaManager, then through the closure into DataObject->requireTable(),
then back into DBSchemaManager->requireTable(). And updateschema() is subclassed in SQLite3, making it difficult to add more arguments.
VACUUM is described as:
> VACUUM reclaims storage occupied by dead tuples. In normal PostgreSQL operation, tuples that are deleted or obsoleted by an update are not physically removed from their table; they remain present until a VACUUM is done. Therefore it's necessary to do VACUUM periodically, especially on frequently-updated tables.
https://www.postgresql.org/docs/9.1/sql-vacuum.html
Since test databases are short-lived, there's no reason to delete dead tuples, they'll be garbage collected when either the transaction is rolled back, or the database is destroyed after the test run.
The query might still work depending on where these chars are placed,
but it seems weird to only remove *some* of the valid chars here.
See https://dev.mysql.com/doc/refman/5.6/en/fulltext-boolean.html
Note that the query runs both the actual boolean query with chars,
and then a separate relevance search without them.
This came up in https://github.com/silverstripe/silverstripe-cms/issues/1452, and wasn't fully addressed.
Either we allow boolean mode and all the constraints this brings around special character usage,
or we filter out those special characters, which makes boolean mode pointless.
You can't just pass arbitrary user input in a power-user function like this.
See https://dev.mysql.com/doc/refman/5.6/en/fulltext-boolean.html
Context: This used to work for some examples like "foo>*" under MyISAM,
presumably because it had a more lenient parser. InnoDB rightfully complains about this now.
MyISAM used to be the only one to support it, now InnoDB has caught up.
Unless an engine is set specifically in create_table_options,
this will auto-convert existing MyISAM tables to InnoDb.
Fixes#9242
API: Query::seek() and Query::rewind() no longer return a value.
Although breaking an API inside a patch release may seem odd, this in
fact is correcting a long-standing bug in our implementation of
Iterator::rewind(), so I think it’s appropriate.
https://github.com/silverstripe/silverstripe-framework/issues/9097