DataList->remove; a heads-up and a question

[Marcus Nyeholt]

One of the big 'oops' that I've been tripped up on with updating some modules to ss3 is the way DataList::remove() behaves. Even though they're quite different, a DataList has been usable in pretty much the same way you'd use a DataObjectSet (which is fantastic for managing backwards compatibility), but they do have pretty big differences in the underlying way of accessing objects. 

Previously, a typical pattern for making sure your list of objects is authorised was to iterated the list, calling 'canView' and ->remove() if that failed. All good with DataObjectSet, because it just removed the object from the backing array of items, however DataList will actually delete the item from the database. A pretty horrifying thing to stumble upon :D

As far as I've seen in the code now, the pattern is to iterate, create a new array (with those passing canView included in the new array) and returning an ArrayList. Is this the preferred approach now?

Cheers,

Marcus

[Sam Minnée]

There is a filterByCallback() method which will help you. But the fact that remove() persists is a big gotcha. Do we need to change this? It would be an urgent RC3...

--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To post to this group, send email to silverst...@googlegroups.com.
To unsubscribe from this group, send email to silverstripe-d...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/silverstripe-dev?hl=en.

[Marcus Nyeholt]

Ah brilliant, I didn't know that existed. 

I don't know if it's needed before release or not; if people try and update legacy code by swapping things step by step, then inevitably people will hit problems pretty quickly. It's the correct code for that usage, so replacing it seems wrong - but it probably needs to be super highlighted in release notes / upgrade guidelines

On the tangential topic, which is the definitive list of defects that need to be resolved before release 1? I've got an issue that I want to push a fix through for that's quite critical (in that some field types no longer work, but only under particular conditions - http://open.silverstripe.org/ticket/7482). Is it the list of 'critical' tickets in the 3.0 tickets report on open.ss? 

Cheers,

Marcus

[Sam Minnée]

On the tangential topic, which is the definitive list of defects that need to be resolved before release 1? I've got an issue that I want to push a fix through for that's quite critical (in that some field types no longer work, but only under particular conditions - http://open.silverstripe.org/ticket/7482). Is it the list of 'critical' tickets in the 3.0 tickets report on open.ss? 

Hi Marcus,

We've released RC2 and our expectation is that this will be the final release.   We've been keeping an eye on critical tickets and making the call on which would block the release, but in general we've moved towards getting it out by the end of June, otherwise SS3 will never be released.

We generally don't have large lists of tickets that must be fixed before a release; we want to focus on schedule first, tickets second.  The definitive lists have been the 3.0.0-rc1 and 3.0.0-rc2 milestones, but both of those are closed now.  Unless something absolutely critical comes out, we're done for 3.0.0.

Most likely, a fix for ticket #7482 would be included in 3.0.1, which I expect will end up following 3.0.0 pretty promptly -- perhaps some time in July?  It will depend on whether anything serious out of the wash after 3.0.0 is released.

Thanks,

Sam

[Marcus Nyeholt]

K cool, a relatively-soon-after point release is good for me

--