I use the method “deleteObject:” to delete a NSManagedObject, but after this I still can print the NSManagedObject although it no longer associates with any other NSManagedObject.
How lead to this and why?
deleteObject: will delete the parameter NSManagedObject from the context. That doesn't mean it will make your object be nil. In fact, it has no way of doing so as you're passing a reference and not the address of it. Most likely it's already doing what you want.
Related
I have a NSArrayController subclass which sets an instance variable of a newly inserted object and prevents the user to remove it if this variable is zero.
I'd like to do this inside an entity subclass. Setting the variable is possible in the awakeFromInsert method. Is there a way to prevent the deletion, a sort of:
if (self.testVariable == 0) return; ?
I didn't find it, but maybe I missed something.
Implement this in your NSManagedObject:
- (BOOL)validateForDelete:(NSError **)error
based on a few tests, i believe the validateForDelete will not work to prevent deletion as desired.
validateForDelete is used to perform added validation prior to delete. essentially, the method name is misleading. Just like for example, for
moreover, prepareForDelete is called prior and will delete any Cascade relationships and mark null any Nullify ones. hence, those have to be 'backed out.' or alter your data model to only permit Deny that will leave those relationships alone in prepareForDelete. which is applying a stiff backhand to your business model and logic.
further, a Deny relationship is 'denied' when the user saves the data -- which might be too late for the user to undo and rectify the situation.
i believe the best option is to unactive the Remove Button that is bound to the canRemove method in the Controller.
Some solid opinions
Some possible solutions at SO
This question covncerns my lack of understanding of how to use the core data undo manager and how to restore a NSManagedObject to its state before editing was done.
I am just learning my way around Core Data. I have my NSManagedObject classes set up with their dynamic accessors. I perform a fetch that returns several NSManagedObject entity results. Content from each of these entity results (first name, last name) get put into a table view, and then the user picks one out of the table for detailed view and then editing.
The detail view controller receives a pointer to the selected NSManagedObject entity. As the user edits the fields, the corresponding property value in the NSManagedObject entity is updated. This seemed like the cleanest way to manage these changes.
Now, rather than committing the changes using save, I want to provide a cancel-editing feature that rolls back to what is in the data base for that entity. I really only want to restore the one entity and not perform the entire refetch.
I tried rollback and I tried NSUndoManager (with beginUndoGrouping and endUndoGrouping), and that is not working. I don't think I understand what rollback is really supposed to do.
But in any case, I still want to restore the property values in just that single entity (taking the lazy approach to only fetch what is needed, which is the one entity) so that my detail view controller can refill its view with the correct information. Right now it is using the NSManagedObject entity values, which contain the edited values, which were cancelled.
I suppose I could just start the edit process by creating a copy of the NSManagedObject. If the cancel-editing button is pressed, I could copy it back into the original. (I might even be able to just replace the original with the copy by moving the pointer. But since the pointer has actually been passed through several objects, I'm not sure how to manage the retain number on the copy.)
Does anyone have any other suggestions?
Thanks
Using rollback should accomplish what you want and I'm not sure what it doesn't. It is probably an implementation detail error.
You can find the specific managed object/s that were updated but not yet saved by calling the context's updatedObjects.
In a subclass of NSManagedObject my overridden implementation of willTurnIntoFault is being called twice when undoing some code which originally created the object in question. This results in a crash when attempting to double-unregister for KVO on a key path.
The Apple documents say this is the right place to un-register for KVO.
A bit of context - the undo operation involves removing the corresponding view of the model from it's superview. The view retains it's model.
So my question is: what kind of programmer errors can result in willTurnIntoFault being called twice in a subclass of NSManagedObject?
Note: Previously I was overriding dealloc in this class but have since realised this is not recommended for subclasses of NSManagedObject. I've since moved this code into -didTurnIntoFault. I'm not currently overriding any other methods which the Apple docs say you should not override.
For posterity's sake: I had the same problem. In my case I had an object A with a (to-one) relation to an object B. When A got deleted B's inverse relation to A was set to null. This caused B's observeValueOfKeyPath:ofObject:change:context method to be invoked (where keypath was B's relation to A). Unfortunately this method checked a property of A, causing the faulting of A to be cancelled (note that in this situation awakeFromFetch does not get called--I presume because the object never actually did get to fault state). Hence I might might get a second call to willTurnIntoFault later and the object would try to unregister for KVO again, resulting in a crash--just like in the OP.
For me the solution was to change the delete rule for A to cascade, so that the B object got deleted when the A object got deleted AND to unregister for KVO in prepareForDeletion. This is important because the deletion of A will still cause B's inverse relation to be set to nil before B is actually deleted.
Note that prepareForDeletion gets called before but not instead of willTurnIntoFault. Hence, if you unregister for KVO in both, you need to maintain some state to make sure you have not already unregistered.
Seems the issue was caused by a custom setter method which was setting/unsetting KVO values from within willTurnIntoFault.
How do I get the value from a SPFieldBoolean object? Do I simply cast it to a boolean or do I need to do something further with it?
I am fetching it in an EventReceiver class during an ItemAdded event from properties.ListItem["fieldname"].
If there is a chance the field might not exist (and be null), how do I check for that?
The value is already a bool, you just need to type-cast it. All fields provide values in their native value-type — see also SPField.FieldValueType property that gives you the actual type in case you need to inspect it on runtime.
To make sure the field is contained in the list, just use the SPFieldCollection.ContainsField method on your list's Fields collection.
I have two entities event and time. The event entity has a 1 to many relationship to time entities as each event can be performed multiple times. Now I want to display all the events chronologically in a tableView. So I set up a fetchedResultsController to fetch all time objects, sort them according to the start time and display the event information by using the relationship to the event object. So far so good. But now if the user tabs an entry in the table I pass an event object to the detailViewController where the event can be edited.
The problem is that now only the event entity is marked as updated. I found this out by looking at the userInfo directory of the NSManagedObjectDidChange notification. In consequence the delegate methods on the FRC are not fired as no time objects have been changed.
How can I manually mark a time object as changed to make the FRC recognize the changes and update the cells accordingly? I tried firing the KVO methods willChangeValueForKey and didChangeValueForKey but it did not work so far.
Thanks alot
Thomas
My model is a little different, but it can easily be translated to your one.
I got a tree-like structure:
Element
title
parent (to-one)
Folder : Element
children (to-many)
File : Element
When a file gets added or deleted, only the first folder in the queue up gets notified about this change. When a file's title changes, not a single folder would get notified. So, what to do?
I tried overriding -willChangeValueForKey: and -didChangeValueForKey: in my Element class.
- (void)willChangeValueForKey:(NSString *)key
{
[super willChangeValueForKey:key];
[self.parent willChangeValueForKey:#"children"];
}
- (void)didChangeValueForKey:(NSString *)key
{
[super didChangeValueForKey:key];
[self.parent didChangeValueForKey:#"children"];
}
Basically, what this does is forcing the parent folder to update because one of its children changed.
Hope it works for you, too.
I'm working through some similar types of updates right now as well. Here's the way I approached the problem.
Let's say we have object A, which relates to object B. B has a property C. We want changes to property C to be reflected in FRCs that use A as the fetched object. What I did to make this happen was to define an accessor to property C from object A:
//A.m
- (void)setC:(int)cValue {
[self willChangeValueForKey:#"b"];
self.b.c = cValue
[self didChangeValueForKey:#"b"];
}
- (int)c {
return self.b.c;
}
This allowed my cells to update based on FRC callbacks with type NSFetchedResultsChangeUpdate. Hopefully this helps solve your problem.
The answer above from #Jenox appears to be the right idea, but it's best to not override those methods as they're called whenever any key is changed on the child object and will probably impact performance and cause unexpected side-effects (it did for me). Probably best to just call them in whatever method you make the changes to the child object in, like this:
- (void)updateFromDictionary:(NSDictionary *)aDictionary {
[myParentModel willChangeValueForKey:#"myChildObject"];
[super updateFromDictionary:aDictionary];
[myParentModel didChangeValueForKey:#"myChildObject"];
}
Note that updateFromDictionary is one of my methods, not a system method.