0

My data model has a ClickerRecord entity with 2 attributes: date (NSDate) and numberOfBiscuits (NSNumber). Every time a new record is added, a different value for numberOfBiscuits can be entered.

To calculate a daily average for the number of biscuits I'm currently doing a fetch request for each day within range and using the corresponding NSExpression to calculate the sum of all numberOfBiscuits values for that day.

The problem: I'm using asynchronous fetch requests to avoid blocking the main thread, so it ends up being quite slow when there are many days between the first and last record. The fetch requests are performed one after another. I could also load all records into memory and perform the sorting and calculations, but I'm worried that it could become an issue when the number of records becomes very large.

Therefore, my question: Is it possible to use NSExpressions to add something like sub-predicates for each date interval, in order to do a single fetch request and retrieve a dictionary with an entry for each daily sum of numberOfBiscuits? If not, what would be the recommended approach for this situation?

I've read about subqueries but as far as I've understood they're not intended for this kind of use.

This is the first question I'm asking on SO, so I hope to have written it in a clear way :)

Rygen
  • 309
  • 4
  • 15

1 Answers1

1

I think what you are looking for is the propertiesToGroupBy (see the Apple Docs) for the NSFetchRequest, though in your case it is not straight forward to implement, for reasons I will discuss later.

Suppose you could specify the category of biscuit consumed on each occasion, and this is stored in a category attribute of your entity. Then to obtain the total number of biscuits of each category (ignoring the date), you could use an NSExpression using @sum and specify:

fetch.propertiesToGroupBy = ["category"]

CoreData will then group the results of the fetch by the category and will calculate the sum for each group separately.

The problem in your case is that (unless you already strip out the time information from your date attribute), there is no attribute that represents the date interval that you want to group by, and CoreData will not let you specify a computed value to group by. You would need to add a new day attribute to your entity, and calculate that whenever you add/update a record, and specify it in the group by. And you face the same problem again if you subsequently want to calculate your average over a different interval - weeks or months for example. One other downside to this is that the results will only include days for which there are ClickerRecords: if the user has a day where they consume no biscuits, then the fetch will not show a result for that day (ie it will not infer an average of 0). You would need to handle this appropriately when using the results.

It might be better either to tune your asynchronous fetch or, as you suggest, just to read the whole lot into memory to perform the calculations. If your entity only has those two attributes, and assuming your users don't live entirely on biscuits, the volumes should not be too problematic.

pbasdf
  • 21,386
  • 4
  • 43
  • 75
  • Indeed the different interval (weeks, months,...) would be an issue. I'll resort to doing the calculations while in memory. The entity will have more attributes but I'll just fetch those two, in order to keep its footprint low. Hopefully for most users the volumes will never be problematic. Otherwise should I add a fetchBatchSize? Thanks for your input! – Rygen Jun 23 '16 at 02:21