Fetching data with relationships directly faults the relationships even when not accessed

Just as an additional information even adding 'propertiesToFetch' to the fetchDescriptor makes no difference

var fetchDescriptor = FetchDescriptor<OrganizationData>()
fetchDescriptor.propertiesToFetch = [\.id]
let organizations = (try? modelContainer.mainContext.fetch(fetchDescriptor))

i have the same issue

Some feedback would be appreciated. I also created a simple test app that reproduces this issue.

@dasdasda Would you mind to make your test project available? I'd try to reproduce the issue and see what happens. Your post can contain a link to where your test project is hosted.

Best,
——
Ziqiao Chen
 Worldwide Developer Relations.

Here is a simple test project:

https://github.com/GNiewoehner/swiftdata-test-app

On start it creates some dummy data, and fetches them without accessing any relationships. The logs are printed to the console.

@DTS Engineer Do you have any update regarding the issue?

Any update?

@DTS Engineer This is still an issue.

For now we stopped using relationships. Instead we store IDs and load entities lazy when accessed.

The only way around it I've found is to create an intermediate 1:1 model that contains the 1:N relationship since SwiftData won't query 1:1 relationships by default.

Just noticed that I hadn't responded this post. Sorry for that ...

I tried the sample project (thanks to @dasdasda) and reproduced the issue on iOS 26 (Beta 4) – fetching Item indeed fetches its itemLinks relationship, even though the relationship is not accessed.

Do you have a feedback report yet? If not, I’d suggest that you file one and share your report ID here. (I can file a report as well, but you represent the developer community. As an originator, you can get notified of the status change and follow up with it if that matters to you.)

Best,
——
Ziqiao Chen
 Worldwide Developer Relations.

Thanks for the replay.

I did not create a feedback report yet but will create one.

For now we moved away from relationships as this was having a big performance impact with our quite large data set. Instead our entities only store IDs of related entities. This prevents any loading of all the related entities, but adds a bit of manual work to handle the lazy loading.

The log lines are actually misleading, it is NOT faulting in the related Models but gathering the related PersistentIdentifiers to use when the relationship is traversed.

Indeed. I looked more closely into the SQLite debug log:

CoreData: sql: SELECT 0, t0.Z_PK, t0.Z_OPT, t0.ZID, t0.ZSOMEPROPERTY, t0.ZSOMEPROPERTY2 FROM ZITEM t0 
CoreData: annotation: sql connection fetch time: 0.0001s
CoreData: annotation: total fetch execution time: 0.0002s for 4 rows.
CoreData: sql: SELECT 0, t0.Z_PK FROM ZITEM1TO2LINK t0 WHERE  t0.ZITEM = ? 
CoreData: annotation: sql connection fetch time: 0.0001s
CoreData: annotation: total fetch execution time: 0.0001s for 4 rows.
CoreData: annotation: to-many relationship fault "itemLinks" for objectID 0x904a44aa77e3d40d <x-coredata://09DF6D0C-702A-4B95-8807-88A11960313E/Item/p1> fulfilled from database.  Got 4 rows
...

The SQL to fetch the itemLinks relationship (SELECT 0, t0.Z_PK FROM ZITEM1TO2LINK t0 WHERE t0.ZITEM = ? ) is basically only for the primary key, and so I won't expect that has a significant performance impact.

Best,
——
Ziqiao Chen
 Worldwide Developer Relations.

Interesting thanks for that. If that is the case the log is indeed misleading and their might be something else that caused the performance issues we had with relationships. As we currently see a significant improvement compared to our initial implementation.