I'm making a new app and I deciced to try to develop it in swift.
I'm using CoreData and I've got a strange behavior I guess.
I'm creating a new Item (NSManagedObject subclass) like this :
let managedObjectContext: NSManagedObjectContext = (UIApplication.sharedApplication().delegate as AppDelegate).managedObjectContext!
self.newItem = NSEntityDescription.insertNewObjectForEntityForName("Item", inManagedObjectContext: managedObjectContext) as Item
self.newItem.setValue(NSDate(), forKey: "startDate")
when I print the startDate, it is always nil. It is the same with the item's properties (link to other objects).
In the debugger, it seems that the object (newItem) is well instanciated (I see a (myapp.Item!) as the object type), but it seems that the debugger is not really user friendly with CoreData. I found no way of inspecting or printing all the object's properties like it was the case in objectiveC.
Is there something I'm missing here? The instanciation seems quite correct to me no?
Thanks.
The fact that you see the object type in the debugger does not mean the object is correctly initialized. It most likely just shows you the type you declared in your class when defining self.newItem.
I agree, the Swift debugger has a lot to be desired. You cannot rely on it to debug this situation, unless you want to learn more advanced debugger commands, but the typing is just as much if you insert log statements into your code instead.
Check and confirm that
your managed object context is not nil
your insert method indeed creates a proper Item object which is not nil
your managed object subclass for the Item entity is properly configured
Maybe you want to try to first create a new local Item variable before assigning it to self.newItem to eliminate any ivar errors.
Try to see if anything changes if you save the context.
Try to get used to accessing the attribute with the subclass properties, such as newItem.startDate rather than relying on the error-prone valueForKey method.
Related
I want to solve next problem:
I would like to work with some NSManagedObject in context and change some properties in runtime, but without telling SQLite about any changes in it.
I just want to save NSManagedObject to database when I hit save button or similar.
As I found out from source code demo we need to use beginUnsafe for this purposes (maybe I am wrong)
func unstoredWorkout() -> WorkoutEntity {
let transaction = CoreStore.beginUnsafe()
let workout = transaction.create(Into<WorkoutEntity>())
return workout
}
let workout = unstoredWorkout()
workout.muscles = []
Now when I try to update workout.muscles = [] app crashes with error:
error: Mutating a managed object 0x600003f68b60 <x-coredata://C00A3E74-AC3F-47FD-B656-CA0ECA02832F/WorkoutEntity/tC3921DAE-BA43-45CB-8271-079CC0E4821D82> (0x600001c2da90) after it has been removed from its context.
My question how we can create object without saving it and how we can save it then when we modify some properties and avoid this crash as well.
The reason for the crash is that your transaction only lives in your unstoredWorkout() method, so it calles deinit, which resets the context (and deletes all unsaved objects).
You have to retain that unsafe transaction somewhere to keep your object alive - such as in the viewcontroller that will eventually save the changes.
But I would rather encourage you to think about that if you really want to do that. You might run into other synchronization issues with various context or other async transactions alive, like when API calls are involved.
During my screen transitions I have a Core data model class object which passes from one to other class. But during this sometimes its "nil" and when I try to log it I find it has returned a fault. While fetching it I have set :
fetchRequestObject.returnsObjectsAsFaults = false
I am new to core data. Below is the log when I tried to print the Object :
Optional<"MyEntity">
- some : <ProjectName.MyEntity: 0x2822acdc0> (entity: "MyEntity"; id: 0x9ddeded1ada58e31 <x-coredata://27FC66FC-4FDF-4B40-9541-F4E90622906C/MyEntity/p34705> ; data: <fault>)
Many times it prints and works fine with its attributes and values. But other times it is "nil".
I have faced similar issue
Faults are in general not something to worry about (CoreData will automatically fire the fault and populate the object as soon as you access any of its attributes).
But in this instance I suspect something more nefarious is happening: the CoreData is instantiated locally in that fetch method, and I fear it is being deallocated (together with the associated managedObjectContext) as soon as the method completes. Your return array consequently contains NSManagedObjects from a context which has been deallocated. To check, try making managedObjectContext a property (a global var) rather than a local variable. That should be enough to keep a permanent reference to the context (which in turn will have strong references to the underlying stack) and prevent it being deallocated.
When I delete an NSMangedObject from the database, what happens to local variables who were assigned to it?
For example, I have a simple NSManagedObject:
class MyManagedObject: NSManagedObject {
#NSManaged var name: String
}
And then in my ViewController, I pull it out of the database, and assign it locally:
class ViewController: UIViewController {
var myManagedObject: MyManagedObject!
}
Then I delete it from the database.
If print the object name I get the following in the console
print("myManagedObject.name = \(myManagedObject.name)")
//prints: "myManagedObject.name = "
As if the object isn't there? But if I turn the variable into an optional and check it for nil, I am told it's not nil.
I'm not quite sure how to reconcile this in my mind. There seems to be something pointing to the local variable, but its properties are gone.
If I have many disparate UI objects that rely on that object for its properties, I can't assume that there is some local deep copy of it in memory?
Here is more complete code:
In viewDidLoad I create the new object, save the context, fetch the object, then assign it locally.
class ViewController: UIViewController {
var myManagedObject: MyManagedObject!
override func viewDidLoad() {
super.viewDidLoad()
//1 Create the new object
let newObject = NSEntityDescription.insertNewObject(forEntityName: "MyManagedObject", into: coreDataManager.mainContext) as! MyManagedObject
newObject.name = "My First Managed Object"
//2 Save it into the context
do {
try coreDataManager.mainContext.save()
} catch {
//handle error
}
//3 Fetch it from the database
let request = NSFetchRequest<MyManagedObject>(entityName: "MyManagedObject")
do {
let saved = try coreDataManager.mainContext.fetch(request)
//4 Store it in a local variable
self.myManagedObject = saved.first
} catch {
//handle errors
}
}
}
At this point if I print the local variable's name property, I get the correct response:
print("The object's name is: \(myManagedObject.name)")
//prints: The object's name is: My First Managed Object
So, now I delete it from the database:
if let storedObject = myManagedObject {
coreDataManager.mainContext.delete(storedObject)
do {
try coreDataManager.mainContext.save()
} catch {
//handle error
}
}
But now, when I print I get the strangest output:
print("myManagedObject.name = \(myManagedObject.name)")
//prints: "myManagedObject.name = "
This is totally not the way I'm expecting memory to work. If I create a instance of a class Foo, and then pass that instance around to different objects, it's the same instance. It only goes away once no one is pointing to it.
In this case--- what is the variable, myManagedObject? It's not nil. And what is the string, name? Is it an empty string? Or is it some other weird meta-type?
The main thing what you are probably looking here for is the core data context. The context is a connection between your memory and the actual database.
Whenever you fetch the data you fetch it through context. These are managed objects which can be modified or even deleted. Still none of these really happen on the database until you save the context.
When you delete an object it is marked for deletion but it is not deleted from the memory, it must not be since if nothing else it will still be used by the context to actually delete the object from the database itself.
What happens to the managed object once you call to delete it is pretty much irrelevant, even if documented it may change as it is a part of the framework. So it is your responsibility to check these cases and to refetch the objects once needed. So you must ensure your application has a proper architecture and uses core data responsibly.
There are very many ways on how you use your database and more or less any of them has a unique way of using it optimally. You need to be more specific on what you are doing and where do you see potential issues so we can get you on the right track.
To give you an example consider data synchronization from remote server. Here you expect that data can be synchronized at any time no matter what user is doing or what part of the application he is.
For this I suggest you have a single context which operates on a separate thread. All the managed objects should be wrapped and its properties copied once retrieved from database. On most entities you would have something like:
MyEntity.findAll { items in
...the fetch happens on context thread and returns to main, items are wrappers
}
MyEntity.find(id: idString, { item in
...the fetch happens on context thread and returns to main, items are wrappers
})()
Then since you do not have any access to the managed object directly you need some kind of method to copy the data to the managed object like:
myEntityInstance.commit() // Copies all the data to core data object. The operation is done on a context thread. A callback is usually not needed
And then to save the database
MyEntity.saveDatabse {
... save happens on the context thread and callback is called on main thread
}
Now the smart part is that saveDatabse method will report to a delegate that changes have been made. A delegate is usually the current view controller so it makes sense to have a superclass like DataBaseViewController which on view did appear assigns itself as a delegate MyEntity.delegate = self, on view did load calls some method reloadData and in the databaseDidChange delegate method calls reloadData and same in viewWillAppear.
Now each of your view controllers that are subclass of DataBaseViewController will override the reloadData and in that method you will fetch the data from the database again. Either you are fetching all items or a single one. So for those singe ones you need to save the id of the object and fetch it again by that id. If the returned object is nil then item was deleted so you catch the issue you seem to be mentioning.
All of these things are oversimplified but I hope you get a basic idea about core data and how to use it. It is not easy, it never was and it most likely never will be. It is designed for speed to be able to access the data even from a very large database in shortest time possible. The result is that it might not be very safe.
Lets say I have the following scenario...
ViewController1 loads a Person object from a Realm on the main thread and passes it to ViewController2. User interaction in ViewController2 causes the same Person object to change, but I only want to persist the changes once the User has pressed "Save".
Currently, when changing the passed Person object in ViewController2 a runtime error is thrown saying changes to an object need to be made in a Write block. This makes sense, but in this scenario I don't actually want to persist the changes right away.
Is there a way to detach an Object from a Realm to avoid these
checks?
If there isn't, what would be a suggested work around? (Copying the Object to a new instance? Tracking the changes to the Object separately and applying them later? Both seem pretty messy.)
Right now, you can make a 'standalone' copy of your object, via Object(value: existingObject) -- that'll probably be the simplest solution for now, until Realm adds something like nested transactions that will make undoing an arbitrary number of changes easier.
Realm has added a freeze() function for Realm Objects on RealmSwift 5.+ versions.
Imagine we have a Realm object Edible with a property name. Previously you weed need to hold a ThreadSafeReference to the object, get a realm on the other thread and unwrap the reference. Meh.
If you didn't, it would crash:
// Code running on main thread
let edible = realm.objects(Edible.self)[0]
DispatchQueue.global(qos: .background) {
let name = edible.name // Realm accessed from incorrect thread error
}
How to do detach an object in RealmSwift 5.+:
let edible = realm.objects(Edible.self)[0].freeze()
DispatchQueue.global(qos: .background) {
let name = edible.name // No longer crashes
}
Keep in mind as of Jan 11 2021, the freeze() function can create a lot of unknown weird errors affecting the users, as mentioned repeatedly in the issues for the new Realm version. For now, stay away from it. Use deep copying.
I have a NSManagedObjectContext where two NSManagedObject are saved.
I'm calling a method in another thread and I need to access those two NSManagedObject so I created a child context like the following:
let childManagedContext = NSManagedObjectContext(concurrencyType: .PrivateQueueConcurrencyType)
childManagedContext.parentContext = self.managedContext
When I do:
let myNSManagedObject1 = childManagedContext.objectWithID(self.myNSManagedObject1.objectID) as! MyNSManagedObject
let myNSManagedObject2 = childManagedContext.objectWithID(self.myNSManagedObject2.objectID) as! MyNSManagedObject
myNSManagedObject1 and myNSManagedObject2 are not the same objects as self.myNSManagedObject1 and self.myNSManagedObject2. Can someone explain me why?
Plus if I use existingObjectWithID instead of objectWithID, it seems I still have a fault object for my relationship in myNSManagedObject1 and myNSManagedObject2:
relationShipObject = "<relationship fault: 0x170468a40 'relationShipObject'>"
Understand that they are the "same" in the sense that they refer to the same object in your object graph. If you compare all attributes, you will find that they are equal.
However, because they are in different contexts, they will be two separate instances of this object. So the machine address you see will be different. I hope that clears up the confusion.
As for the "fault", that only means that the underlying object (or attribute) has not yet been fetched into memory. This is simply an optimization mechanism to minimize memory footprint. If you were to log the object or attribute explicitly, it would be fetched from the store and displayed as expected. See "Faulting and Uniquing" in the Core Data Programming Guide.
You have one object, that is the version that's in Core Data. When you use objectWithID: you create an instance of that object. So, if you do it twice you get two instances of the same object. (Much in the same way that you can create two objects of the same class.)
Of course, if you try to save your context, having changed one but not the other, weird things might happen.
A common pattern is where you create a new "editing" managed object context and create a new instance there. Then if the user pressed Cancel, you can just delete the context and not have to worry about rolling back any changes. I can't think where having two instances on the same context would be useful.