It is not uncommon for an index to be defined as e.g. 'fulltext'
which SQLite3 does not support without a module to create a
virtual table (rather than an index on an existing one). The code
already in place sees that definitions be updated to 'index' on
the fly during creation and later inspection (indexList) - which
causes issue when comparing existing table definitions to what
SilverStripe expects by DataObject configuration. This discrepency
leads to tables constantly being marked to update, although
effectively nothing actually changes. We can save these CPU cycles
and a bit of head scratching by converting to a supported index type.
The logic for cancelling a savepoint was incorrect, as the behaviour
the logic was modelled on was for a different RDBMS - where a COMMIT
would always close the most recently opened transaction.
SQLite on contrast will commit the entire transaction, not just the
most recent savepoint marker until current execution point. The correct
manner to deal with a 'partial' commit is to call RELEASE <savepoint>.
This revealed an error in the savepoint logic, in that if someone had
supplied a savepoint name instead of relying on generated ones, the
rollback command did not factor for this and always assumed generated
savepoint names - again causing error. For this reason a new class
member field has been introduced to track savepoint names in a stack
fashion.
Transactions that used more than one level would cause errors if
there were consecutive calls to start a transaction - because each
query executed would clear the flag indicating that a transaction
was already in progress.
The comment for the logic to reset the nesting level on a query was
indicating that DDL (data definition language) would not work within
a transaction. This is untrue, and the module itself uses a transaction
to alter table or field names. So this function has been converted to
a no-op, deprecated to be removed in version 3 of this module. It is
also no longer called upon each query.
There have been some maintenance tidyups around this area also by
abstracting the nested transaction flag manipulations into protected
functions.
Instead of using a custom "memory" key in the $databaseConfig
which never really got used this now allows someone to simply enable
in-memory databases by setting the path to ":memory:" or to use the
following environment variable:
define('SS_SQLITE_DATABASE_PATH', ':memory:');
As opposed to LIKE, the GLOB operator is case sensitive by default
in SQlite3. It uses "*" instead of "%" for wildcards,
which necessitated a new SearchFilter->getWildcard() method.
SQlite3 doesn't support per-term modifiers,
COLLATE BINARY LIKE is case insensitive by default
unless the field collation is set up accordingly.
There's connection-level modifiers (PRAGMA case_sensitive_like = true),
but that would affect all comparisators in the executed query.
While the SQLite3 module is predominantly used for testing,
its best to leave this decision to the code using it.
We should default to a conservative setting (slower, but persistent).
Also remove coupling to SapphireTest when setting this value.
Don't bother creating the directory if running in-memory.
