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.
Code in the field alteration logic had a queries defiend as strings to
begin and commit transactions involve with changing table or column names.
This was causing fatal errors as BEGIN is not a valid keyword within
a trasaction (see SQLite documentation excerpt below).
A new api has been introduced to deal with transactions programmatically,
and this module was updated to support this a few months ago. This is a
tidy up of some missed portions - consuming this API which correctly uses
SAVEPOINT when a nested transaction is required automatically.
https://www.sqlite.org/lang_transaction.html
Transactions created using BEGIN...COMMIT do not nest. For nested
transactions, use the SAVEPOINT and RELEASE commands.
Enum values are themselves enumerated in sqlite as they are not supported
as a type. This leads to values being stored in their own table, and a
regular TEXT field being used in a MySQL ENUM's stead. The default value
for this field was being escaped with custom string replacement, and
erroneously relacing the backslash (a redundant operation). This lead
to invalid Fully Qualified Class Names in SilverStripe 4, which is a
required trait for polymorphic relationships. As a result any polymorphic
relationship not set on first write would then proceed to cause an execution
error the next time the dataobject with the relationship was fetched from
the database. By using the PHP supplied escape function for SQLite3 we can
avoid this, and restore functionality.
Relevant section of SQLite documentation to justify the removal of escaping
various characters, such as the backslash:
A string constant is formed by enclosing the string in single quotes (').
A single quote within the string can be encoded by putting two single quotes
in a row - as in Pascal. C-style escapes using the backslash character are
not supported because they are not standard SQL.
https://www.sqlite.org/lang_expr.html
Elliot Sawyer
Maxime Rainville
NightjarNZ
Damian Mooyman
Daniel Hensby
helpfulrobot
ClayLennart
Damian Mooyman