I have two entities in my CoreDataModel that should be linked together with a too-many relationship on one wary and to-one on the other way.
These are the CityEntity and the WeatherEntity.
The CityEntity can have multiple WeatherEntity, but not the opposite.
I have two main errors that I would like to solve.
When saving the data, the NSManagedObjectContext save as many CityEntity as I have WeatherEntity, which is wrong as I am expecting only one CityEntity.
When saving WeatherEntity, the relationship with the CityEntity is not created.
This is the code I am using to save the data.
func saveForecast() {
let cityModel = CityModel(
name: "Paris",
weather: [WeatherModel(temp: 12.65), WeatherModel(temp: 12.43)]
)
let cityEntity = CityEntity(context: persistentContainer.viewContext)
cityEntity.name = await cityModel.name
for weather in await cityModel.weathers {
let weatherEntity = WeatherEntity(context: persistentContainer.viewContext)
weatherEntity.temp = weather.temp
weatherEntity.city = cityEntity
}
do { try persistentContainer.viewContext.save() }
catch { print(error.localizedDescription) }
}
These are the result that I get saved in my CoreDataModel, which is wrong as I have 3 CityEntity instead of one, and no relationships between my WeatherEntity and the expected CityEntity.
You can see that there is not CityEntity saved in place of the name when looking at the `WeatherEntity.
This is the way I set the relationship in the CoreDataModel:
It seems that you (accidentally?) set the parent entity of WeatherEntity to CityEntity. That makes WeatherEntity a “sub-entity” of CityEntity, and the corresponding WeatherEntity class a subclass of CityEntity.
Then every instance of WeatherEntity is also an instance of CityEntity, and that explains why there are three instances of CityEntity in total after running your code.
Resetting the parent entity to “No Parent Entity” in the Core Data model inspector, re-generating the managed object subclasses, and cleaning all application data should solve the problem.
I am finishing up an app utilizing a local Realm database with three models. When I delete an object from the main master model, the connected objects in the child models are supposed to all delete, but only one of the objects in each model deletes. See the attache diagram.
Not sure where to go next. Any help will be greatly appreciated!
Thanks!
Blessings,
—Mark
This is the normal behavior of realm js.
When you delete one element of the master model, the child element related is still present on the database.
The only solution is to get all child element and delete them first.
For example if you have a Master model named "Order" and a child model named "customer" :
/** if you use realm-js **/
const order = realm.objects('Order').filtered(`id = 1`)[0]
realm.write(() => {
realm.delete(order.customer)
realm.delete(order)
})
also you can find related related post with the same question
here or
here
Anyone else with this question, knowing the child databases must be deleted first, the solution became self-evident. Thanks again for pointing this out!.
//get the object at indexPath.row
let a = self.master![indexPath.row]
let id = a.Id //master's record ID
let n = realm.objects(Child1.self).filter("Id = %#", id)
let r = realm.objects(Child2.self).filter("Id = %#", id)
//Delete object at indexPath.row
try! realm.write {
realm.delete(n)
realm.delete(r)
//delete last
realm.delete(a)
}
Blessings,
—Mark
In my app I am using a NSPersistantContainer with two NSManagedObjectContexts (viewContext & background context). All my read operations are performed on view context, while all my write operations are performed on the background context (shown below).
Creating a new Animal class
class func new(_ eid: String) {
//Create Animal Entity
let container = CoreDataService.persistentContainer
container.performBackgroundTask { (context) in
let mo = Animal(context: context)
mo.eid = eid
mo.lastModified = Date()
mo.purchaseDate = Date()
mo.uuid = UUID()
do {
try context.save()
}
catch let error {
print(error)
}
}
}
The problem I am having is I need to return the newly created NSManagedObject (Animal) back to the manager class, where the Animal.new(eid) was called, to be used to show the object properties.
I have experimented with using a completion handler, but had issues returning the value, as was using a background NSManagedObject in the main thread.
Using possible new function
Animal.new(eid) { (animal) in
if let animal = animal {
}
What is the best approach for returning a newly created NSManagedObject, created in a background context?
What I do is to keep my CoreData managed objects within my CoreDataManager class, not exposing them out to the rest of my framework. So methods that are to create one or more managed objects would accept the data as an unmanaged object, and then create the managed object but not return it (as callers already have the unmanaged object). When fetching from the CoreDataManager, I'd create and populate a unmanaged object(s) and return that.
Now part of why I do this is because I'm using CoreData in a framework, such that I'd never want to hand a managed object to a client app of my framework. But it also solves other problems like the one you described.
(When I write apps, I use Realm, and those objects can go straight to app's UI classes because Realm is so much easier to, erm, manage. :)
Context
I have problems using the method realm.add(object, update: true) successively.
I'm making WEB requests to my API, and I'm testing the case where internet connection is disabled. When a request failed and I get the response, I add an UnsynchronizedRequest realm object to Realm.
Problem
I have to test the case where I have to make multiples call to my API, so I will add multiple UnsynchronizedRequest objects to Realm.
I only start the next web request when I received the previous request response, so the requests are well chaining, there is no concurrent requests.
When I'm making only one request and that it failed, the object is well added to Realm.
But when I'm making more than one request, only the first is added to the Realm, and the others are not added.
What is strange is that when I'm using breakpoints, all objects are well added to Realm. But when I disable breakpoints, only the first UnsynchronizedRequest object is added to the Realm, the other are ignored.
I think it is a problem with the write thread, the doc says that it blocks other thread if multiple writes are concurrent, but I don't know how to solve it.
What I execute when a web request failed :
class func createUnsynchronizedRequest(withParameters parameters : Parameters, andRoute route : String){
print("Adding unsynchronized request to local...")
let failedRequest = UnsynchronizedRequest()
failedRequest.parameters = parameters
failedRequest.route = route
failedRequest.date = Date()
RealmManager.sharedInstance.addOrUpdate(object: failedRequest)
}
RealmManager.swift
func addOrUpdate(object : Object){
try! realm.write {
realm.add(object, update: true)
}
}
UnsynchronizedRequest.swift
#objcMembers class UnsynchronizedRequest : Object {
// MARK: - Realm Properties
override static func primaryKey() -> String? {
return "id"
}
dynamic var id = ""
dynamic var route = ""
dynamic var date : Date! {
didSet {
self.id = "\(self.date)"
}
}
}
I already tried to check if realm was in transaction in the addOrUpdate method before starting realm.write, this not solve the problem.
I also tried to catch the error with realm.write, but no error is thrown.
Furthermore, if I execute for example 3 time a web request et that is failed, I'm sure that my code is executed because the print in createUnsynchronizedRequest is working.
I really think it is a problem with write threads because when I use breakpoint to slow the code execution, everything works well.
Example with 3 failing web requests and USING BREAKPOINTS :
As you can see, using breakpoints, the 3 objects are well added to realm :
Example with the same 3 failing web requests and WITHOUT BREAKPOINTS :
But now without breakpoints, only the first object is added to Realm :
Any idea ?
As I created my UnsynchronizedRequest objects with the Date() method, the created objects had the same primary keys.
The space time between object creation is not sufficient to make a Date() object different than the previous created.
I've created simple entity 'CDWorkout' with one attribute 'name' inside CDModel.xcdatamodeld. Name of container in AppDelegate is also 'CDModel'. Class Codegen for 'CDWorkout' is Category/Extension. Here is code for CDWorkout class:
class CDWorkout: NSManagedObject {
class func createWorkout(workoutInfo : Workout, in context: NSManagedObjectContext) -> CDWorkout{
let workout = CDWorkout(context: context)
workout.name = "anyName"
return workout
}
}
the createWorkout function is called from another viewController with context argument as container.viewContext but it immediately crashes with message:
Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: 'An NSManagedObject of class 'Workout_Generator.CDWorkout' must have a valid NSEntityDescription.'
What did i forget about?
The issue I had was that I needed to have the Class Module set to Current Product Module for my CDWorkout Entity.
In Xcode 10 there is a drop down in the Class section of the Data Model Inspector.
I had a silly minor issue that resulted in the same error. I was initializing NSPersistentContainer with the incorrect name.
It should have the same name as the source file with the extension .xcdatamodeld. e.g. modelFileName.xcdatamodelId
let persistentContainer = NSPersistentContainer(name: "modelFileName")
In my case the same problem was in #objc modifier in auto-generated header of data-class
#objc(CachedMovie)
public class CachedMovie: NSManagedObject {
I just removed #objc(CachedMovie) and it began to work
I came across this same error message when trying to insert/add a managed object from an extension (SiriKit). It seems to have been an issue with the namespace of the extension not matching the .xcdatamodeld file, because I was creating the entity description using MyClass.entity().
The combination that worked for me was:
#objc(MyClass) at the top of each NSManagedObject subclass
Entities in the data model use the default "Global namespace", not "Current Product Module"
Create the entity description using let entity = NSEntityDescription.entity(forEntityName: "MyClass", in: context)!
In AppDelegate check persistent container name.
let container = NSPersistentContainer(name: "CoreData")
If you trying to reach nonexistent Core Data, that may manifest as this error.
Name should be exact same as .xcdatamodeld object in navigation menu.
If you are using coreData from a static library make sure you specify the module aswell
This gives you the correct entity access MyStaticLibrary.MyManagedObject
So if your receiving warnings with this dot notation, its not looking in your module
One way this could happen is by trying to rename your entities. Make sure that these are the same!
I've got the same issue. In my case I used CoreData initialised and managed in framework wich I integrated with main app via SPM.
Solution
First, in the framework provide module name for entity by hand, by following steps:
open .xcdatamodel,
select Entity which you want to edit,
open Data Model Inspector (the 4th panel in right sidebar),
at section Class element Module by default presents Current Product Module -- enter here your Module name
Repeat these steps for each entity.
Second, in the framework override description for each NSManagedObject you use in project, f.ex. you have:
public class Person: NSManagedObject {
}
override there description with String without module name, like:
public class Person: NSManagedObject {
public override var description: String {
return "Person"
}
}
Code presented above will help if you use convenience initialiser for Person (like Person(context: Context)) which uses description to specify Person.entity().
For me, I forgot to add #objc(Reminder) in this below example. I wrote the NSManagedObject class programmatically.
#objc(Reminder)
public class Reminder: NSManagedObject {
}
I encountered this issue using Swift Package Manager to import a Swift Package that had a model file included as a resource. In my case setting the Module of my entity to Current Production Module produced an incorrect value in the model file. When I used the debugger to print the model after loading the persistent container the fully qualified class name was something like Module_Module.Class instead of the expected Module.Class. I had to manually type the module name instead of using Current Production Module to resolve the issue.
in your file modeldataClass
probably name of Class is incorrect cause before you change name something in your name class
The mistake I made was to change the name of the entity and the generated "NSManagedObject Subclass" and not updating the name of the class. How to fix:
open .xcdatamodeld
click on the entity
open the right panel
Go to Data Model Inspector
Change the name of the Class text field
What fixed it for me was that I had an empty space in the name and didn't notice because of a line break. Removing it fixed the problem..
It was:
container = `NSPersistentContainer(name: "ContainerName ")`
Instead of:
container = NSPersistentContainer(name: "ContainerName")
I had similar issue in CoreData stack with NSManagedObjectModel made from Swift code. The issue was in wrong value for NSEntityDescription.managedObjectClassName attribute. The Swift module prefix was missed.
Correct setup:
let entity = NSEntityDescription()
entity.name = PostEntity.entityName // `PostEntity`
entity.managedObjectClassName = PostEntity.entityClassName // `MyFrameworkName.PostEntity`
entity.properties = [....]
Where: entityName and entityClassName defined like this.
extension NSManagedObject {
public static var entityName: String {
let className = NSStringFromClass(self) // As alternative can be used `self.description()` or `String(describing: self)`
let entityName = className.components(separatedBy: ".").last!
return entityName
}
public static var entityClassName: String {
let className = NSStringFromClass(self)
return className
}
}
I was trying out adding CoreData to existing project and I renamed things a lot. I ended up with multiple .xcdatamodeld without knowing it. The solution was removing .xcdatamodeld and generated NSManagerObject and recreating it again.
it easy to answer to this question. without removed
#objc(Workout)
the solution is on documentary Core Data Programming on "Entity Name and Class Name".
here in your Xcode before doing (Editor -> Create NSManagedObject SubClass)
must change your class Name of Entities to add "MO", CoreData can differentiate between class Name and Entitie Name. and the
#objc(Workout)
will not be created, give us this one:
class CDWorkoutMO: NSManagedObject {
class func createWorkout(workoutInfo : Workout, in context: NSManagedObjectContext) -> CDWorkoutMO {
let workout = CDWorkoutMO(context: context)
workout.name = "anyName"
return workout
}
}
like I do on my Xcode
For SwiftUI you need to also update this method from SceneDelegate:
func scene(_ scene: UIScene, willConnectTo session: UISceneSession, options connectionOptions: UIScene.ConnectionOptions) {
//This gets the context from AppDelegate and sets is as moc environment variable
let context = (UIApplication.shared.delegate as! AppDelegate).persistentContainer.viewContext
let contentView = ContentView().environment(\.managedObjectContext, context)
//...
}
In my case, I had my Core Data model inside a Swift Package and had to follow this amazing guide and finally this is what did it:
I opened the model and selected the entity and in the right panel I selected the Data Model Inspector and in the Class panel, I manually entered the Module’s name i.e. the Swift Package name.
For me this worked,
Adding
#objc('YourEntityClassName')
above the class declaration in 'YourEntityClassName+CoreDataClass' file.
Note: I am using this in an SPM package.