I'm following this tutorial for organizing code in rest kit
http://restkit-tutorials.com/code-organization-in-restkit-based-app/
I want to separate my domain model from restKit mappings.
so I added all my mapping to a class named mappingProvider.
RKEntityMapping *tableMapping = [RKEntityMapping mappingForEntityForName:#"Table" inManagedObjectStore:[HAObjectManager sharedManager].managedObjectStore];
tableMapping.identificationAttributes = #[#"tableID"];
[tableMapping addAttributeMappingsFromDictionary:#{
#"ID":#"tableID",
#"TableNumber":#"tableNumber",
#"NumberOfChairs":#"numberOfChairs"}];
mapping provider needs a reference to ManagedObjectStore which I try to get from my custom subclass of RKObjectManager named HAObjectManager.
HAObjectManager calls [self setupResponseDescriptor] which this method calls
RKResponseDescriptor *tableResponseDescriptors = [RKResponseDescriptor responseDescriptorWithMapping:[MappingProvider tableMapping] method:RKRequestMethodGET pathPattern:#"/api/table" keyPath:nil statusCodes:RKStatusCodeIndexSetForClass(RKStatusCodeClassSuccessful)];
[self addResponseDescriptor:tableResponseDescriptors];
again this method calls [MappingProvider tableMapping] which again this calls [HAObjectManager sharedManager] to get managedObjectStore . as you see this causes and infinite loop.
does anyone know how should I solve it?
for example a sharedInsatnce of coreData managedObjectStore.
You need to change your initialisation order, which isn't necessarily trivial given your described structure. Most options are unpleasnt without doing significant rework.
A simple option for breaking the recurs ion is to add a parameter to tableMapping such that you can pass the object store as a parameter (so you don't need to call back to the partially initialised singleton to get it).
Related
I have a core data database. I'm performing a custom migration. I have a subclass of NSEntityMigrationPolicy. My policy's migration method buildValueFromSectionFieldManagedObject: is being called by a mapping rule : FUNCTION($entityPolicy, "buildValueFromSectionFieldManagedObject:" , $source).
This part is actually working.
However, the implementation of buildValueFromSectionFieldManagedObject: uses methods in the custom entity NSManagedObject subclass of the $source, which is Choice.
The methods of Choice do not seem to be available to the migration function, and instead it gets just a vanilla NSManagedObject.
When I try to use Choice methods, I get an exception. If I po the choice in the debugger, I get something like this:
<NSManagedObject: 0x600000281860> (entity: Choice; id: 0xd00000000038001a ; data: )
Whereas, out of a migration I would usually see something like this:
<Choice: 0x60800028bdb0> (entity: Choice; id: 0x6080002225a0 ; data: {
Is this just how it is, or is there some way that I can use the entity objects during migration?
Possibly relevant – this particular entity, Choice, is removed during this migration. It does not exist in the target managed object model, but does exist in the source managed object model. However, I don't think this is the case as other entity classes that are in the target model are also unavailable as that class during migration – they have class NSManagedObject and their entity methods are not available.
That is correct, you only have access to basic NSManagedObjects during migration.
Three-Stage Migration
The migration process itself is in three stages. It uses a copy of the source and destination models in which the validation rules are disabled and the class of all entities is changed to NSManagedObject.
From: Core Data Model Versioning and Data Migration Guide
Dave's answer clarified that during a migration, core data object are only available as NSManagedObject instances. You don't get to use their Entity classes.
Worse, if you're using a tool like mogenerator, then any handy logic that you've extended the entity classes with is inaccessible.
Poor solutions
Working with an NSManagedObject directly feels dangerous to me. Using [managedObject valueForKey:#"someKey"] is verbose, but worse, there's no compiler checking that you've got your key name correct, so you might be asking for something managedObject doesn't have. There's also no compiler checking of the returned type either – it could be anything that you can put in to a managed object.
Slightly better is [managedObject valueForKey: NSStringFromSelector(#selector(someKey))] is safer, but horribly verbose and awkward, and still isn't that safe – lots of things might implement the method someKey.
You might also declare your keys as literals:
NSString *const someKey = #"someKey";
[managedObject valueForKey: someKey];
Again – this is slightly safer, less error prone and verbose, but you've got no guarantee still that this managed object has someKey.
None of these approaches will give us access to custom logic, either.
Better solution
What I did instead of this was to define a protocol for the properties that I know my managed object has. Here's are examples for entities Choice and ChoiceType.
#protocol ChoiceProtocol
- (NSSet<id <ChoiceTypeProtocol> > *)choiceTypes;
- (NSNumber *)selected;
- (NSNumber *)order;
#end
#protocol ChoiceTypeProtocol
- (NSNumber *)selected;
- (NSString *)name;
- (NSString *)textCustom;
- (NSNumber *)order;
#end
Now in my migration code, instead of having a custom migration function similar to:
- (NSString *)migratedRepresentationOfChoice:(NSManagedObject *)choice;
I have:
- (NSString *)migratedRepresentationOfChoice:(id <ChoiceProtocol>)choice;
In the body of this function I can use choice exactly as I would any regular object. I get code completion as I type, I get the right syntax highlighting, the compiler will complain if I call a non existent method.
I also get return type checking, so the compiler will complain if I use the NSNumber property selected as an NSString or NSSet. And it'll also be helpful and suggest NSNumber methods as completions while I type.
How about the logic?
This approach doesn't provide the logic you've added to entity classes.
In Swift you might be able to use a protocol extension to achieve that.
I was retiring these entities (hence the migration), so I moved the entity logic functions I needed in to a helper functions of my custom migration. As an example choice.orderedChoiceTypes becomes [self choiceOrderedChoiceTypes:choice].
In future I will probably avoid ever adding logic to NSManagedObject entities. I think it's probably a better plan to put any such logic in domain objects that you build from your managed objects. Further, I will probably avoid defining entity classes and instead only access NSManagedObject instances through a protocol as during the migration. It seems clean, simple, removes magic, and has benefits for testing – not just for migrations.
I'm attempting to map the inverse relationship for the RKEntityMapping of my ManagedObjects, but I'm having some difficulty getting things to work. I'm exchanging data with Parse.com and I am able to perform my GET requests without issue as well as mapping the results into Core Data. The problem arises when I attempt to perform a putObject operation that contains a relationship to another object.
Per the Parse.com documentation: https://www.parse.com/docs/rest#objects-updating, the request needs to look similar to the following:
'{"opponents":{"__op":"AddRelation","objects":[{"__type":"Pointer","className":"EquipmentType","objectId":"Vx4nudeWn"}]}}'
I've subclassed RKObjectManager to encapsulate all of my mappings as follows:
_entityMapping = [self createMappingForEntity:[EquipmentState class]];
[self addResponseDescriptor:_entityMapping withPathPattern:[EquipmentState pathPattern]];
[self addRequestDescriptor:[_entityMapping inverseMapping] class:[EquipmentState class] rootKeyPath:nil];}
[_entityMapping addPropertyMapping:[RKRelationshipMapping relationshipMappingFromKeyPath:#"type" toKeyPath:#"type" withMapping:[EquipmentTypeManager sharedManager].entityMapping]];
I am mapping my EquipmentState class, which has a relationship to EquipmentType. When I perform my GET request, RestKit is able to successfully map the objects without issue. However the same cannot be said when I perform a PUT. Clearly this is an issue with my mapping but I don't know how I can define a mapping that will produce similar output to the above.
Thank you for the assistance.
I have an NSManagedObject subclass with a transient property which is basically a reformatting of one of the persistent to-many relationships. I do this by observing the relationship with KVO and registering the observer in -awakeFromFetch, -awakeFromInsert, etc.
This all works fine, however if I pass the object between threads using the object's objectID and -objectWithID: technique there is no life-cycle method into which I can hook generation of the transient property. None of the life-cycle methods are triggered, in fact, since accessing the object directly using the id isn't considered a fetch, it seems.
There are ways around this, but it would be nice to use a life-cycle based technique. Am I perhaps missing something? Is there another standard method I could be using?
Thanks
Edit: Demonstration project
https://mega.co.nz/#!UsNBTZ7S!UU1qaFuc4W6Z2EYey-9AiMyfM8203Zfrm1lfpG5QITU
When you have a NSManagedObject instance on one thread with a context and then retrieve it from a different thread and different context the -awakeFromFetch or -awakeFromInsert fires.
Are you using the contexts properly so that you are retrieving a new instance?
Have you looked at the pointers in the debugger to make sure you are talking to a new instance of the NSManagedObject?
In my experience those lifecycle methods fire per context.
Ok, so to answer my own question, the issue is caused because objectWithID: always returns an object, even though the object isn't registered in the receiver managed object context. Seems in some circumstances objectRegisteredForID: is more informative. In any case, the conclusion is that the life-cycle methods do fire, but to take care with objectWithID: since it can result in an inconsistent object.
I encountered this same issue, and solved it by creating an extension on NSManagedObjectContext that goes through the normal fetch pathway, therefore triggering all of the expected lifecycle methods:
extension NSManagedObjectContext {
func fetchObject<T: NSManagedObject>(with objectID: NSManagedObjectID) -> T? {
let request = T.fetchRequest()
request.predicate = NSPredicate(format: "SELF = %#", objectID)
guard let result = try? fetch(request) else {
return nil
}
return result.first as? T
}
}
Is there an easier way to do something like the following in Core Data:
Entry *entry = [[Entry alloc] init];
entry.name = #"An Entry";
[entry save];
I realize you don't have to allocate an NSManagedObject, have to insert directly into the context like the following:
Entry *entry = [NSEntityDescription insertNewObjectForEntityForName:#"Entry"
inManagedObjectContext:[self managedObjectContext]];
But this is a lot of code. Also I would like to save by just messaging rather than have to save the entire context:
NSError *error = nil;
NSManagedObjectContext *managedObjectContext = self.managedObjectContext;
if (managedObjectContext != nil)
{
if ([managedObjectContext hasChanges] && ![managedObjectContext save:&error])
{
NSLog(#"Unresolved error %#, %#", error, [error userInfo]);
abort();
}
}
Could I put these in an NSManagedObject abstract class and have my managed objects extend that abstract class? Basically, I'm just trying to encapsulate more in my models and write less code in my controllers. Any help appreciated.
You can define your own subclass of NSManagedObject, and set all of your entities to use it.
The subclass can have whatever initialiser/save patterns you define, so long as it calls the proper parent class's initialiser.
You could have a +entity method, which might link to a statically defined context (this will restrict you to a single managed object context of course, but that's not always bad as long as you can also call the more primitive initialisers when you need a second context).
You might even have a +entityWithName: method.
As for saving the context, once again you can always define a subclass and add a simple -save method which saves the context and throws an exception if the save fails. You may choose to do this with a category extending the NSManagedObject class, instead of a subclass.
Note it is impossible to save just the change you made to that one entry object. You can only save all changes to an entire managed object context. If you need to save a single record, then you need to create a temporary managed object context, make a single change in it, then save the temporary context, and then sync the temporary context change over to all other managed object context's that currently exist in the app (there is an API to do make this complicated process relatively easy).
I don't like the code you posted to save the context, for several reasons:
Don't define a managedObjectContext variable that just points to self.managedObjectContext. In almost all situations that's an extra line of code for no benefit. At best you're making your code hard to read, at worst you might be introducing bugs.
Why are you checking if it is nil? Usually you should design your code so that it cannot ever be nil. Do the nil check in the constructor of your object, and if it's nil that is a critical failure. Your whole app is completely useless for the user, and you should make it clear to the user that they can't use the app by doing something drastic, such as a crash (an error alert first would be nice, but I wouldn't bother. I'd just throw an exception).
Why are you doing a check for hasChanges? I cannot think of many situations where you would need to do this check. Perhaps your app is allowing a user to make many changes, and then saving them several minutes later? This is bad. The context should be changed milliseconds after a group of changes are made, or else you're risking data loss. Your app could crash, the phone could run out of battery, or the user might receive a phone call and your app is consuming enough RAM that the OS will terminate it instantly in order to present the "incoming call" screen. You shouldn't need to check for hasChanges because you always perform a save operation immediately after making some changes.
As I kind of mentioned before, if the save fails you should present an error to the user then throw an exception. Avoid using NSLog() in deployment code, it's really only useful for development and beta builds.
Check out
NSManagedObject+ActiveRecord.h
Inside Restkit : http://restkit.org/
It is based on :
https://github.com/magicalpanda/MagicalRecord
I am using in RestKit app, but you can adopt it quite easily.
Good luck
I have a question that keeps bothering me. Currently, I have started using Kohana 3.2 Framework. I've written a helper to handle some functionality - I have a number of methods, which are (as it should be) declared STATIC. But, all of these methods are somehow working with the database, so I need to load a model. Currently, every method has a non-static variable like this:
$comment = new Model_Comments;
$comment->addComment("abc");
OK, it seems to be working, but then I wanted to get rid of this redundancy by using class attribute to hold the instance of the model (with is class as well).
Something like this:
private static $comment; // Declaring attribute
self::$comment = new Model_Comment; // This is done within helper __constuct method
self::$comment->addComment("abc"); // And call it within the method.
But, I got failed with: Call to a member function addComment() on a non-object
Question is: is it possible to do it ? Maybe there are some other approaches ?
Sorry for a long story and, thanks in advice! :P
A static method cannot call a non-static method without operating on an instance of the class. So, what you're proposing won't work. There may be a way do accomplish something similar, but what about trying the following:
You could implement the singleton or factory pattern for your "helper" class. Then, you could create the model (as an attribute) as you instantiate/return the instance. With an actual instance of your "helper" class, you won't have to worry about the static scope issues.
In other words, you can create a helper-like class as a "normal" class in your application that, upon creation, always has the necessary model available.
I'd be happy to help further if this approach makes sense.
David