realm-swift
realm-swift copied to clipboard
realm
Add ability to sort RLMResults using a comparison block
We should discuss the feasibility of this, especially around auto-updating. It may not be fully possible to do this without the ability to freeze RLMResults. If that's the case, we should add the blocked tag to this issue.
The API could look something like -[RLMResults sortedResultsUsingBlock:], which would require constructing the accessors for each item in the RLMResults and then accessing the properties accessed in the block, but it would allow people to sort in any way they like.
Thoughts @alazier @tgoyne?
I don't think this is something we will want to do. First it requires creating accessors for every element which can get kind of slow. Second, we will have to hold onto the sort block as long as the RLMResults exists and to reapply that block for live queries. This obviously has potential problems.
I think what we should do instead is to bring back the arrayForRange: pr and allow users to sort the NSArray using a block. The key is that users understand they are creating an array of accessors, and providing such a method where they do this explicitly is probably the best way to accomplish this.
I agree there are disadvantages to this approach, but it's still better than the alternatives. Unless there's another solution that we have yet to consider.
I can think of a few downsides to encouraging users to use an -[RLMResults arrayWithRange:] method for custom sorting:
- It's error-prone. If a user forgets to recalculate their sorted array when data changes, not only will they be accessing stale data, but they'll likely also be accessing invalid objects.
- It's a different interface. If users are already displaying an RLMResults and they want to tweak how it's sorted, they'll have to refactor the code accessing the data. If (when) we create a suite of UIKit extensions to back controls by Realm, we'd need to support both interfaces.
- It's complicating a common use case. Custom sorting is a common enough feature request that it's worth us doing once rather than many of our users independently.
- A user's solution is likely to be slower than ours. This is pretty safe to assume. If someone comes up with a faster way to do it, they'll hopefully share their approach with us so we can improve ours, to everyone's benefit.
This being said, there might be another approach we have yet to consider, but until then, I think an -[RLMResults sortedResultsUsingBlock:] is our best bet.
Just +1ing this.
I'm currently trying to sort an array of locations by a computed 'distance' property. This 'distance' property represents the distance between the location and a user selected point.
I've been using RLMResults as my data model for my tableview, as it has sorting built in. Unfortunately, was a bit stumped and now will have to use standard arrays.
I guess we should add this and make clear in the docs that performance will be much worse than using sortDescriptors.
This is still blocked on core support support for manual construction and freezing of TableViews
+1
I'm dealing with the same use case that @ceeK highlighted, sorting on a computed distance property.
Adding my +1 to this. Even if using this came with a significant performance tradeoff versus sort descriptors (when using the feature, obviously), it has to be better than my "map to an array, run a custom sort, and regenerate on every write notification" solution I'm currently stuck with.
This would also give relief to the "sort on relationship properties" crowd (#1277) while they wait for support within sort descriptors (myself included!).
More specifically if we could have the localizedStandardCompare: option such as in NSFetchedResultsController that would cover 99% of cases. I'm not sure if that would be any easier to implement on its own.
+1 here as well. Trying to sort based on one optional NSDate and another non-optional NSDate. Trying to look at whether the optional date exists and if so us it for sorting, if not fall back to the non-optional date.
you should also annotate that sortedResultsUsingDescriptors expects an array of RLMSortDescriptor not a NSSortDescriptor...
+1 for needing it with distance.
Even if I have my own in-memory array of location id's sorted by distance, I still can't sort the RLMResults using that array, as the only thing I can sort on is dumb, stored values in the DB.
This really is a serious limitation. Seems to me that -[RLMResults sortedResultsUsingBlock:] and/or -[RLMResults sortedResultsUsingPredicate:] are a central requirement to loads and loads of use cases.
