BUG Fix DataObject / Versioned publishing issues

[tractorcow]

This issue was initially raised at and fixes silverstripe/silverstripe-blog#105.

After investigation I found the following issues.

If a DataObject was queried under a certain stage or reading mode, and then this mode changes, lazy-loading of fields would fail since it will always attempt to use the current mode. This is fixed in DataObject::loadLazyFields so that any DataObject will maintain it's own query parameters internally, propegating this context from initial load all the way to lazy loading of fields.

This fix was made in DataObject rather than in Versioned::augmentLoadLazyFields because (in my humble opinion) it's the role of the DataObject to maintain its own query context, and it should only be touched by extensions to modify this explicitly. This is easier than updating each dataobject extension across the board.

Secondly, Versioned::writeToStage was failing if no fields were modified, meaning simply loading a record from one stage and writing it to another would result in no write performed.

Test cases were included in VersionedTest rather than DataObjectLazyLoadingTest becuase I feel that this is more a test of the Versioned extension (and DataObject's support for extensions) than the lazy loading process itself. I could just as easy have put it there though. :)

I've marked this as "don't merge" because I'd like to get a few developer opinions before I'm confident this is the correct solution.

[tractorcow]

@sunnysideup would you like to peer-review my PR? :)

[sunnysideup]

Sure, what is the best way to do this? review the code or how it works or both etc...???

[tractorcow]

I just wonder if my thinking is correct in the getSourceQueryParams part of the code; If a dataobject is queried, is it wise to do a blind restore of the original query parameters when lazy loading?

[tractorcow]

Removed the "don't merge" - I think this can go into core as long as it's checked by another developer before they merge it.

[sunnysideup]

I just had a first look. It seems to make sense.

what if Query Params are already set, will it double-up or have too many query params? I am not sure if that is even relevant, but just wanted to check. I dont think this is an issue - and I think you are basically wondering about the same thing. I just wonder how I can even test this.

because it such a CORE CORE change, would it be worthwhile to work out how much longer it takes to run the code to avoid it slowing down EVERYTHING? This would be fairly easy to test and it is important to know.

[tractorcow]

Thanks for the review. :)

QueryParams are already set in the DataQuery constructor to the current defaults, such as versioned stage, etc. The code above simply overwrites any default keys with those saved on the DataObject, so it won't remove any keys. This might cause problems if any extension relies on the absence of any query param to work...

I don't think it's going to be a performance hit; It's just copying variables from one object into the DataQuery.

[simonwelsh]

I saw an old issue that this fixes too. I guess I'll have to go find it now :p