2

i'm having some issues with core data, so i hope that someone will be able to help me :)

First problem, i have a data model that looks like this :

 Entity P (A) <----> Entity R
  / | \
 / /\ \ 
/ / | \ \
C D E F G

All my entities inherit from the same entity "P" because they need a common attribute and a common relationship ("A" and "R")

The problem i am getting is that core data uses generates only one sqlite table for all the entities when you use inheritance. In my case it means that my database will have only 1 table for all the datas. I did some research and i saw that it creates performance issues (moreover all my entities attributes are transients and during willSave their values are aggregated+encrypted into one NSData stored in "A", so i won't be able to use predicate to filter and improve SELECT performances). So i decided to remove "P", and to add "A" into "C", "D"..., "G". The problem is with "R", because before i had only one inverse relationship in it, and now i need to create one each time i create a new kind of entity. So i would like to remove all the inverse relationships, is it possible? Sometimes i need to create managed object with a nil context, and i insert them into the context later, this is probably why the inverse relationship are not automatically set by core data if i set the non-inverse before the insertion in the MOC right ? Anyway i never need the inverse, so can i avoid defining them even if i get a warning ?

2nd problem, in specific situations i need to create a new "R" and to assign it to "C", "D",.., "G" during the MOC save. So i would like to use willSave but, i don't know if the created entity will be saved. If the MOC does a simple loop over the "insertedObjects" / "updatedObjects" / "deletedObjects", and for each object it calls willSave, does the save, and then calls didSave, it means that i'm going to modify the array on which it is iterating, and then it should crash no?

LiohAu
  • 611
  • 12
  • 36
  • 1
    RE the inverse problem. You don't have to explicitly set the inverse relationship up. As long as you have the inverse relationship set up in the schema then when you add the relationship one way CoreData sets up the inverse for you automagically. – Fogmeister Sep 25 '12 at 09:01
  • 1st, it seems that it is not the case if the object is created with a "nil" MOC, the relationship is set, and then the object is assigned to the MOC. 2nd, i don't want to define the inverse in the schema, if i have to do it, each time i will create a new entity, i will have to create its inverse. – LiohAu Sep 25 '12 at 11:01

2 Answers2

0

Core data is not a wrapper around your sql tables. It deals with object graph and its persistence. SQLite store is just one way of persisting it. Check this up. Prevent Core Data From Combining Entities into One Table

Community
  • 1
  • 1
Rakesh
  • 3,370
  • 2
  • 23
  • 41
  • From the topic you just quoted : "If you have a large number of objects of the same entity inheritance tree you might hit some performance issue at the very high end e.g. 20k+ objects but otherwise not.". As i said, i have a fully encrypted database, this means that core data won't be able to do a lot of things to optimize, no predicate, no sorting.... – LiohAu Sep 25 '12 at 08:51
  • Core Data is not just persisting objects, it comes with a lot of functionalities like undo management, schema migration, validation etc. You are getting all this with a small overhead. For core data optimizations check out this apple documentation on core data. https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/CoreData/Articles/cdPerformance.html#//apple_ref/doc/uid/TP40003468-SW1 – Rakesh Sep 25 '12 at 11:30
0

As you and I both independently found out the hard way, be very, very careful with entities which inherit from each other. I too found Core Data tends to make one giant table containing all the fields for the base entity and all entities which derive from it, so any given entity contains the fields for every potential entity from its furthest ancestor downwards. Very, very slow and expensive.

I highly recommend only having the entity classes themselves inherit from each other, and mirroring the properties of the base class in all entities instead, without any actual inheritance in the managed object model itself.

Andy Riordan
  • 1,154
  • 1
  • 8
  • 13
  • This is what I finally did... Even if there's a ZENT field in the tables that contains the entity type which is probably indexed and used by core data to pull less data, that still generates tables with a lot of rows. – LiohAu Dec 24 '14 at 13:16