Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

moonman239

Cancelled
Original poster
Mar 27, 2009
1,541
32
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.
Code:
//NSManagedObject subclass
-(void)awakeFromInsert

{

    [superawakeFromInsert];

    if (!self.placeIndexPath) {

        [self setPlaceIndexPath:[[NSMutableArrayalloc] initWithObjects:[NSIndexPathindexPathForItem:0inSection:0], nil]];

        }

}

Code:
// 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:
Code:
//UserEntity.h
@interface UserEntity : NSManagedObject



@property (nullable, nonatomic, retain) NSString *name;



@property (nonatomic) int16_t nextLevel;

@property (nonatomic,strong,readonly) NSArray *placeIndexPath;

@end
//UserEntity.m
@interfaceUserEntity ();

@property (strong,nonatomic) NSMutableArray *placeIndexPath;

@end
 
Last edited:

Mascots

macrumors 68000
Sep 5, 2009
1,667
1,418
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.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.