A few bug fixes and changes to make the injector play better with existing code.

[nyeholt]

Driven by the change for singleton and strong_create to use dependency injector.

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.

[halkyon]

Sorry Marcus, I've had to revert this because it broke a lot of unit tests. Could you please look into that and open another pull request?

[nyeholt]

Hmm, which tests? I wonder if my version was slightly out of sync - is there a log somewhere?

[halkyon]

@nyeholt Here's the log: http://teamcity.silverstripe.com/viewLog.html?buildId=7388&buildTypeId=bt27&tab=buildLog

[nyeholt]

So locally all tests are passing, so I'll need to check whether there's been some commits since my changes that have gone a bit haywire. The only other difference I can see is that I'm running phpunit 3.6 and that's running 3.5, but I doubt that's causing the issue. Will look into it a bit later today after a couple of meetings

[nyeholt]

Is it possible for someone to apply the following patch (https://gist.github.com/2772403) to a local sapphire instance and run their tests locally? I'm not getting any of the errors as output by the build bot, and it'd be good to figure out if someone else can duplicate the failures :)

[halkyon]

I get the same issues locally as the buildbot.

Here's one of the failures:

DataExtensionTest::testAddExtensionLoadsStatics
Couldn't run query: UPDATE "DataExtensionTest_Player" SET "ClassName" = 'DataExtensionTest_Player', "Status" = 'Goalie', "Name" = 'Joe', "DateBirth" = '1990-05-10', "Address" = '123 somewhere street', "LastEdited" = '2012-05-23 01:29:04', "Created" = '2012-05-23 01:29:04' where "ID" = 1 | no such column: Status
user_error(Couldn't run query: UPDATE "DataExtensionTest_Player" SET "ClassName" = 'DataExtensionTest_Player', "Status" = 'Goalie', "Name" = 'Joe', "DateBirth" = '1990-05-10', "Address" = '123 somewhere street', "LastEdited" = '2012-05-23 01:29:04', "Created" = '2012-05-23 01:29:04' where "ID" = 1 | no such column: Status,256)
Database.php:658

SS_Database->databaseError(Couldn't run query: UPDATE "DataExtensionTest_Player" SET "ClassName" = 'DataExtensionTest_Player', "Status" = 'Goalie', "Name" = 'Joe', "DateBirth" = '1990-05-10', "Address" = '123 somewhere street', "LastEdited" = '2012-05-23 01:29:04', "Created" = '2012-05-23 01:29:04' where "ID" = 1 | no such column: Status,256)
SQLite3Database.php:181

SQLite3Database->query(UPDATE "DataExtensionTest_Player" SET "ClassName" = 'DataExtensionTest_Player', "Status" = 'Goalie', "Name" = 'Joe', "DateBirth" = '1990-05-10', "Address" = '123 somewhere street', "LastEdited" = '2012-05-23 01:29:04', "Created" = '2012-05-23 01:29:04' where "ID" = 1)
Database.php:606

SS_Database->manipulate(Array)
DB.php:174

DB::manipulate(Array)
DataObject.php:1155

DataObject->write()
DataExtensionTest.php:88

[halkyon]

Tests are run using php framework/cli-script.php dev/tests/all flush=all

I'm using PHPUnit 3.6 as well, so it can't be that. :)

[nyeholt]

Ah, you're running using sqlite? Lemme check that then...

[halkyon]

I think it's failing in MySQL too...

[nyeholt]

Yeah I think it's to do with flush=all in combination with tests/all and how everything gets re-inited. I can run the individual test class on its own and it completes successfully, but run as dev/tests/all flush=all and it'll fail.