When publishing to live, DataObject#forceChange is called, which wasnt correctly loading
in fields that were lazy (unloaded) if those fields were from composite fields
like Money. The end result is that any Money values would be forced to null on
publish to live
Also changes the API of the (internal, protected) loadLazyFields method so that
not passing a class argument just unlazys all lazy fields regardless of source table
In getField we check if the field we are getting is currently lazy (unloaded), and
load it if it is. This was only working for simple fields though - composite
fields like Money werent working
When querying DataObjects by a generic parent class (like SiteTree for instance), fields added via $db
set on child classes wouldnt appear.
This is because Object::__construct wasnt called early enough in DataObject::__construct, so
extensions werent initialised when $db was first accessed
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.
PaginatedList needs to be notified about this, otherwise it will
errorneously try to further limit the already limited set, making the
subsequent pages empty.
Without this bugfix, if you had a Page that used to be a SiteTree, and you tried to use Versiond::get_version() or Versioned::get_latest_version() to return the older SiteTree version, nothing would be returned, because the results were being filtered by ClassName. This caused bugs in the history panel for certain combinbations of page classname alteration.
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.
The intl extension in PHP 5.4 provides a Transliterator class, which
conflicts with the SilverStripe one. This leads to some really weird
ReflectionExceptions about Transliterator's constructor being
private.
DataObject::__construct()
The database adapter uses smallint instead of the boolean datatype,
which works around the issue instead of converting the value.
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
MINOR Use injector for creating many many list objects
MINOR Use injector for creating objects from within the DataList
MINOR Use Injector::inst() for creating objects; cannot rely on this->injector being present due to many classes being created with 'new', so use inst() directly
MINOR Remove injector autoset property for now; automatically setting it breaks a few test cases that don't know about it for now, and it's not needed just yet
BUGFIX Versioned's constructor doesn't provide suitable defaults. Previously a bug/feature in singleton, where it would pass null,true as params to strong_create, which would then get passed through as params to Versioned's constructor, meant that the code still executed fine (as was set to something that wasn't an array, so the null and true were instead taken as args). The fact that the usage of singleton(Versioned) never really used the classes code, purely for value lookup, meant that this never propagated errors. I've now switched singleton() to use the injector for retrieving values, which means these dud values are no longer passed through
CHANGE Given that Config::inst is an implementation of the singleton pattern itself, I've removed the extra call to singleton(). A side effect of this is that it gets around a possibly nasty circular reference with the dependency injector (which relies on the config object); in future, this dependency structure should really be structured from the DI directly.
MINOR Change singleton and strong_create to use dependency injector
