0

im building an app using coredata that will have following entities .. events(ie things to do), items(ie things available), requests(ie request for help). i want a table view where i can display all the above items which users can filter in various ways .. ie only show items, only show events, only show all in a certain time frame etc. my original idea in coredata was to make an entity called post and make that the parent entity of the event, item, and request entities. That way i could do a single fetchedresultscontroller (FRC) to populate the main tableview.

however ive run into problems with coredata creating correct nsmanagedobject subclasses using this structure and also read a few SO posts advising against parent-child structure in coredata when the database grows in size Core Data Performance with Single Parent Entity

so now, unless someone advises me otherwise, ive gone back to using separate item,event,request entities. now im trying to workout how to populate a main table with all these entities in a single table regardless of type, allows the filtering required above, and allows users to select a cell and have that table cell present the details of the selected cell. with this last requirement i assume ill need to pass the selected managed object of a certain entity type to the details screen and then do a swich on its type. any advice appreciated.

Community
  • 1
  • 1
lozflan
  • 835
  • 10
  • 23
  • What sort criteria will you have in your table? Are you happy for each object type to be listed separately, eg. in a separate section? – pbasdf Mar 18 '15 at 22:39
  • i want to sort mainly by date/time that the post is entered (post being a generic term for any entity ie item, event, request etc. i will also want to sort by other criteria such as expiry date, distance from user etc... so essentially it is important for me to have a master tableview that shows all types of entity in a single sorted list .... i also intend to allow users to see each object type listed separately as youve indicated above but i assume that will be easier to achieve because i can have a single FRC applicable to each list – lozflan Mar 19 '15 at 05:12
  • 1
    That's going to be difficult; I ended up using an FRC for each entity and having the different objects in separate sections. That way It's quite easy to map FRC indexPaths to the tableView indexPath. If you need them intermingled but don't want to use parent-child entities, could you instead have one entity holding all the common attributes (eg date, expiry date, distance, etc) and with separate 1:1 relationships defined for each type of post? – pbasdf Mar 19 '15 at 08:35
  • thx ... so it seems my options are either back to parent child entities, or one entity with common attributes and relationships to each type. assuming post numbers could be very large, what are pros and cons of each option... from your comments it appears ill have to have a single large table in the database holding all posts (common elements) whichever way i go.. (if i want to continue to use FRC to populate the tableview i assume) – lozflan Mar 19 '15 at 21:06
  • Yes, I think that's true: if you want to use a single FRC, you will need (one way or the other) a single entity with most of the attributes. The "multiple-relationship" solution I proposed has the disadvantage that the FRC delegate methods will not be called if the destination object changes. So of the two options I think I would stick with parent-child entities. I did investigate subclassing the NSFetchRequest underlying the FRC, to secretly undertake three fetches and return a combined result - but I quickly got out of my depth and concluded it was a bad idea. – pbasdf Mar 20 '15 at 09:08
  • If you have three separate entities, the main problem is sorting (and grouping) the results of three fetches (or three FRCs) into a single array to underpin the table view. Effectively you will have to build FRC functionality without using an FRC. Even more complicated if you want to replicate the FRCs delegate methods to update your TV. So perhaps parent-child is the best way to go. Sorry I can't be of more assistance. – pbasdf Mar 20 '15 at 09:19
  • thx @pbasdf. ive gone back to using parent-child and i seem to have sorted the previous problems i had with not being able to create the correct MO subclasses... essentially the problem of the subclassess not being created properly was fixed if i deleted the class from finder and then recreated them in xcode. also after recreating the MO subclasses i needed to reclassify them as "my project name".Item for example in the entity class field in the coredata model to have the classes be recognized. thx again for your suggestions ...how can i mark your comments as the solution? – lozflan Mar 24 '15 at 00:27
  • Thanks, but I don't think my comments add up to an answer - you've done all the hard work! Why not add your own answer setting out how you've finally resolved it, for others to use if they have a similar situation. – pbasdf Mar 24 '15 at 00:33

1 Answers1

0

there were 2 main coredata problems i had 1. xcode was not correctly creating my nsmanagedobject subclasses and 2. i wasnt sure how to model the entities (parent-child vs separate) so that i could populate a single tableview with all the entities from a fetchedresultscontroller (FRC) and then filter later by various criteria ie entity type, add date etc.

i ended up working out how to to correct the way that coredata created the subclasses by following the following instrux Create NSManagedObject subclass not generating property after updating to Xcode 6.0

then i reverted back to parent-child entities and used a single FRC to populate the tableview .....

Community
  • 1
  • 1
lozflan
  • 835
  • 10
  • 23