FIX: Compatibility with versioned DataObjects

[nedmas]

As in #21 it would be great if the GridFieldOrderableRows supported versioned DataObjects. So I thought it would be good to start a discussion regarding the best solution as I agree with @ajshort that coupling the components should be avoided.

My suggestion is that the current implementation that uses DB::query() to update the sort order is replaced with DataObject::write(). This would ensure that all the relevant pre/post write code gets run (including all the versioned related code).

However I recognise that this will add a certain amount of overhead to re-ordering, is this acceptable or is there a more elegant solution?

[ajshort]

A benchmark is probably the only way to find out.

[MattyBalaam]

Did this ever get looked at?

[nedmas]

Hey @MattyBalaam I don't think that this has been looked at (I certainly haven't I'm afraid). However there is this module (https://github.com/heyday/silverstripe-gridfieldversionedorderablerows), that I've used on a couple of projects, which might help.

[MattyBalaam]

Thank you, I will investigate.

[nyeholt]

(Andrew's assigned the module over as he's taking a back-seat in SS land for a while, hence the lack of attention to the issue).

My understanding of the way the sort functionality is being triggered is to avoid (potentially) loading lots of data objects and triggering lots of ->write() calls when re-ordering items - given moving an item at the head of the list towards the back of the list triggers updates on all the items in-between.

Now, if the current list being displayed is relatively small, that's not really a problem, but if you're displaying 100s at once, it might be; has someone got a sample implementation? It's probably something that could be done as a configurable option?

[MattyBalaam]

The module above shows how it can be done, it is an extension to this. Moving objects is a slight fudge as any changes seem to go live immediately, rather than just to a draft. But, data objects have always seemed to work this way anyway.

[nyeholt]

Yep, implementation wise there's no real issue, but there is the problem of which implementation approach should be taken, given the possible tradeoffs.

• Direct DB::query() calls (fast, but don't trigger write() based extensions). Can be adapted to update _Live tables immediately to directly publish changes to sort order
• Calling write() for each data object affected - could be 'expensive' for gridfields set to display a large number of items - and again, should it immediately call 'publish' after 'write'?

So there's two somewhat related implementation problems; is the sort update done using DB::query or ->write() (regardless of versioned status of the dataobjects being manipulated), and separately, should all items be immediately ->published() afterwards?

I'm thinking that both could be solved with configurable settings when creating the GridField config - will take a look over the next few days (and see if there's some code I have from a client project that might help for a 'publish all changes' type of button).

[colymba]

Any update on this? Especially now with SS4 taking an "everything Versioned" approach, this is a big issue...

[mlewis-everley]

Just to pipe up here, we have tried https://github.com/heyday/silverstripe-gridfieldversionedorderablerows as mentioned by @nedmas and it works pretty well.

The auto publishing is an issue though, I have to admit the only way I could see fix it might be to use a gridfieldcomponent that auto publishes it's list when the parent is published (rather than automatically publishing on change)?

[ivoba]

Just stumpled over this as well with SS4.
Current state is when reordering versioned DataObjects only the DataObject table is updated.
No Draft is mentioned on owning Object and when publishing the Owner it doesnt have any effect on the ordered DataObject.
So basically have to save every DataObject that was affected by the ordering to take effect on Publish.

Im not sure how the Draft state is triggered but i would welcome if the silverstripe-gridfieldversionedorderablerows module mentioned by @mlewis-everley would trigger this instead of a automatic publish.
The current automatic publish bypasses also onAfterPublish hooks.

In the meantime i will try silverstripe-gridfieldversionedorderablerows.

[ivoba]

i think this was mostly solved with d1021ac

No?

[dhensby]

fixed by #243

[kinglozzer]

I’m not sure this is entirely resolved - this module will still only save draft versions when changing the sort order, there’s no way to automatically propagate that change to live. Use case example: a lumberjack GridField containing a lot of child pages - auto-publishing the children when the parent is written is really slow, as a bunch of changeset records are created

I’d like to see this as an opt-in API, I wrote this extension of the existing GridFieldOrderableRows class which achieves that: https://gist.github.com/kinglozzer/c585e0ffe67757c29f15c44349a4e4e2