Core Data not saving - again

Discussion in 'iOS Programming' started by moonman239, Dec 29, 2015.

  1. moonman239, Dec 29, 2015
    Last edited: Dec 29, 2015

    moonman239 macrumors 68000

    Mar 27, 2009
    I realize I created another thread like this two years ago. My problem then was a bit different.
    My problem now is this: I have an NSManagedObject containing an NSMutableArray of NSIndexPaths. As before, all changes persist only in RAM.
    Edit: My NSMutableArray is stored in Core Data under a "Transformable" attribute.
    //NSManagedObject subclass
        if (!self.placeIndexPath) {
            [self setPlaceIndexPath:[[NSMutableArrayalloc] initWithObjects:[NSIndexPathindexPathForItem:0inSection:0], nil]];
    // Code I use to save a new index path.
        [[UserEntity sharedEntity].placeIndexPath insertObject:newIndexPath atIndex:level]; // This works.
        NSError *error;
        if (![[[UserEntity sharedEntity] managedObjectContext] save:&error]) {
            NSLog(@"An error occured while trying to save the user's place: %@",[error localizedDescription]);
    I enabled SQL debugging & checked my log, and it shows that my app is SELECTing, but not UPDATEing. No errors were printed.

    Edit #2: It looks like I hit a little quirk: Apparently, Core Data has a little problem with mutable types of classes. It doesn't like the fact that I've declared an NSMutableArray property; the workaround, apparently, is to configure my property accessor so it returns an immutable type. I can still use an NSMutableArray, however, to store my property's values.

    Edit #3: Tried this, and it didn't work:
    @interface UserEntity : NSManagedObject
    @property (nullable, nonatomic, retain) NSString *name;
    @property (nonatomic) int16_t nextLevel;
    @property (nonatomic,strong,readonly) NSArray *placeIndexPath;
    @interfaceUserEntity ();
    @property (strong,nonatomic) NSMutableArray *placeIndexPath;
  2. Mascots macrumors 68000


    Sep 5, 2009
    This is very complex and you may want to take a second, take a breather, and take a step back to look at your overall model.

    Is there a reason you're storing a NSIndexPath? Ideally, you'd want to store the data that's valuable or unique in as basic of a form as possible. Even though Core Data wraps values in Foundation objects, it's best to think primitive types since the underlying engine is SQL. There's no need to work with that extra unnecessary, and potentially massive, data because it can't be indexed, which means you can never search, analyzed, or used build fast indexes to SELECT to benefit SQL.

    With a subclass, you can write a computed setter that extracts the information from NSIndexPath and a matching getter that returns a NSIndexPath, all while storing the data as Ints, either in a relation or a string value normalized by a getter or setter.

Share This Page