Lazy loading no longer loads fields from the versions table when querying. This could lead to incorrect data being displayed if the data on the object and the version it pointed to did not match.
API methods to allow setting of the context of the query that generated the DataObject on that object (used by the lazy loading mechanism to correctly query the Stage, Live, or Versions tables)
See https://github.com/silverstripe/sapphire/pull/1178 for context.
This bug will surface when using the ORM and adding an join to DataList
where a DataObject inherits another DataObject.
If you for example want to restrict the number of pages that only have a
related Staff object:
$list = DataList::create('Page')
->InnerJoin('Staff', '"Staff"."ID" = "Page"."StaffID");
This will create a SQL query where the INNER JOIN is before the
LEFT JOIN of Page and SiteTree in the resulting SQL string. In MySQL
and PostgreSQL this will create an invalid query.
This patch solves the problem by sorting the joins.
The entire framework repo (with the exception of system-generated files) has been amended to respect the 120c line-length limit. This is in preparation for the enforcement of this rule with PHP_CodeSniffer.
The augmentSQL DataExtension method is always extended on the base data
class of data objects in DataQuery::getFinilisedQuery(). This results
in augmentSQL not being called for extensions that are applied to non-
base data classes when finalizing the query.
For example, if Versioned was applied to class B which extends class A,
which in turn extends DataObject, then augmentSQL would be extended for
class A in DataQuery::getFinilisedQuery(). Since class A doesn't have
the Versioned extension in this example, it would not work for class B.
Fixed this by extending augmentSQL on the actual data class and not
on the base class.
If the applyRelation() was passed a relation that went to a class with a parent
class with a database table, applyRelation would return the name of the parent
class, rather than the class the relation was actually too.
This bug was caused by the fact that SQLQuery::whereAny() removed existing filters. In line with addWhere() and setWhere(), I split this into addWhereAny() and setWhereAny(). Strictly speaking, this drops the method SQLQuery::whereAny(), but it was really just an internal function for exclude, and so I think that's acceptable.
MySQLDatabase::enumValuesForField() - Added stripslashes because backslashes are escaped in the type description
DataObject::requireTable() - Added double quotes to column names in automatically generated indexes for many_many relationships
DataObject::write() - Escaped class name for DB query
DataQuery::getFinalisedQuery() - Escaped class names for DB query
API CHANGE: Deprecated SS_List::getRange() in favour of SS_Limitable::limit().
API CHANGE: Introduce SS_Limitable::limit($limit, $offset = 0) as the only modern way of specifying limits; deprecate all others.
