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
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
BUGFIX: Provide default constructor values for classes (fixes issues when used in 'singleton' scenario during dev/build in particular)
MINOR Clear out injector state when resetting db schema during tests (a follow on from changing singleton() calls to use the injector underneath)
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
