The right ancestor class that has the Hierarchy extension applied needs to be used
since it doesn’t have to be the class directly extending from DataObject, which means
the ID and ParentID columns might be in different tables.
If the content is invalid for whatever reason e.g. when instantiating
a DBText field to get a summary of text through
`DBField::create_field('Text', $content)->Summary(10)`, preg_split returns
false and the rest of the code expects an array.
This tweak ensures an array is always returned even when preg_split fails.
This provides a mechanism for adjusting the behaviour of these
relations when building more complex data models.
For example the following example has a status field incorporates a
Status field into the relationship:
```php
function MyRelation() {
$rel = $this->getManyManyComponents(‘MyRelation’);
$rel = $rel->filter(‘Status’, ‘Active’);
$rel->addCallbacks()->add(function ($relation, $item, $extra) {
$item->Status = ‘Active’;
$item->write();
});
}
```
Introduces a new library dependency: http://github.com/sminnee/callbacklist
The exists query in SQL allows the query optimiser (engine specific) to execute these queries much faster - often only needing the presence of an index to return "yes it exists".
When many-many-through relations are queried, a joinRecord is set on
each DataObject in the list to provide the extra fields defined on
the connector object. This didn’t previously happen when the record
was first add()ed to a list. This fixes that bug.
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
