SOLVED: When to use FetchRequest?

@Benji

Jan '23

Something I'm trying to figure out for a while:

A Core Data App I'm working on has a parent Entity with several one-to-many relationships to other Entities. It's structure would look like this:

CarBrand > Dealers > Cars available CarBrand > Factory > Models

Let's assume this app doesn't contain any network calls, everything is just entered and stored locally on-device (as the above structure is just a sample).

I'm only fetiching data from CoreData when the app launches. Once I add a new dealer, car, factory... these automatically appear in the list of available Cars thanks to how SwiftUI works. However, I've seen other apps that would fetch data from the database on every single view, so in the example above: CarBrandList: initial Fetch Request > DealersList: Fetch Request > Available Cars List: Fetch Request.

Does that give me any benefits like performancewise? Or would it even put more workload on the app?

Many thanks!

@Obelix

Jan '23

@Benji is trying to load some CoreData concepts into his longterm memory banks:

... fetch data from the database on every single view.....Does that give me any benefits like performancewise?
Or would it even put more workload on the app?

These are concepts that database programmers have always battled. Access vs Performance. Fresh data vs Stale data.

Please note: I don't back up my observations with hard scientific proof.

But in my readings and education journey, I've settled on a comfort level that unless I'm working with tons of data, millions of records, the performance of chips in iPhones and iPads will never be challenged by CoreData lookups. Also, CoreData was written by boffins who baked in caches and fetch optimizations, leaving you to focus more on the business at hand.

Have you bought Donny Walls' book?

See -> Practical Core Data

It's your fault!

In Chapter 4, he discusses some of your points. Pay particular attention to faults.

Chapter 4:
..... snip ...... In addition to learning more about retrieving data, you will also learn about faults, batch insert,
delete, and update requests, merge policies, and query generations. By the end of this chapter,
you should have a pretty solid understanding of how you can manipulate the data

10/10 Would recommend. 👍🏼

Apple's documentation:

Faulting reduces the amount of memory your application consumes. A fault is a placeholder object that represents a managed object that has not yet been fully realized or a collection object that represents a relationship...

CoreData is vigilent in keeping its object graph optimized when your application is in play. So while you may load a number of Dealer objects from your persistent store, CoreData may only load a portion of that Dealer's Car objects, or load placeholders. CoreData works hard to prevent you from loading objects, until you actually need them. (See documentation and Wal's book for more in-depth knowledge.)

See -> It's your fault!

Brief excerpt:

When a fault is fired, Core Data does not go back to the store if the data is available in its cache.
With a cache hit, converting a fault into a realized managed object is very fast—it is basically the same
as normal instantiation of a managed object. If the data is not available in the cache, Core Data
automatically executes a fetch for the fault object; ....snip.....

Xcode and Instruments

Finally, tell us how you're using Xcode's Instruments application. Are you profiling your CoreData app?

Please share how Instruments reveals interaction between your CoreData API calls, and the data residing on your device. This may be revealing!

Watch -> WWDC 22 Instruments and CoreData

Keep coding!

Please share your CoreData results with us!

@Benji

Jan '23

Thanks @Obelix!

Have you bought Donny Walls' book?

Back when I bought it, it felt like it was way above my head, so yeah I should take another read these days. Good point.

Finally, tell us how you're using Xcode's Instruments application. Are you profiling your CoreData app?

Uhm...to be honest, never got into that. I'll put that onto my list, too.

There is so much more to learn about CoreData, but there are only very few tutorials using CoreData AND SwiftUI that go deep enough. With no experience in UIKit the older tutorials available are quite hard for me personally to get into.

Too bad Mark Moeykens book is delayed.

I'll try to get into the things you mentioned sooner rather than later and report back where that led me!

For now: Thanks again!

I'll keep this thing open for a few more days as the above may lead to more questions!

Sponsor Hacking with Swift and reach the world's largest Swift community!

Archived topic

This topic has been closed due to inactivity, so you can't reply. Please create a new topic if you need to.

All interactions here are governed by our code of conduct.