I have a Core Data model with an entity whose parent is an abstract entity. The implementations of the classes are in Swift. There is a single property and a single relationship established in the abstract entity, with some other properties and a relationship on the concrete entity.
I'm hitting a strange issue now. When I add a nillable convenience initializer (public convenience init?) or a throwing one (public convenience init(...) throws) to the concrete entity, I start getting an NSInvalidArgumentException like so:
-[MyModel.ConcreteEntity setAbstractAttribute:]: unrecognized selector sent to instance 0x7aa75a10
When I I remove the ? and throws from the signature, I don't get that exception. What can I do to allow this?
Related
I am trying to understand the syntax for initializers and how they work. I am reading the swift documentation and I am having a hard time understanding how they work in a specific example I am working on. I'm following a tutorial to learn about core data but I do not want to continue through the project until I understand how the initialization code works (or any other concept I do not understand).
https://docs.swift.org/swift-book/LanguageGuide/Initialization.html
Core Data: Note Entity Class
Core Data: Note Class Convenience Initializer
In the first image above I show the Note Entity Class that Core Data creates and in the second image I add a convenience init(). All the extra on the code in the extension of the Note class is my notes.
The first two comments on the extension of the Note class is what I have found out about how the entity class hierarchy which is that the super class is the NSMangedObject (super class) then the sub class is the Note entity class. To my understanding the NSMangedObject class has 3 initializers which are:
init() - Default Initializer
init(entity: NSEntityDescription, insertInto context: NSManagedObjectContext?) - Designated Initializer
convenience init(context moc: NSManagedObjectContext) - Convenience Initializer
Then Note entity class the only thing I have is the convenience init(title: String, context: NSManagedObjectContext). For this initializer I understand how the title and creationDate are initialized but my question is on the self.init(context: context).
Question: To my understand reading the Swift documentation a convenience initializer cannot point to another convenience initializer which is what I think it's happening here?? I think that the default initializer from the Note class is pointing to the initializers from the super class of NSMangedObject. Can anyone provide me with some insight to understand what is happening.
A convenience initializer must call another initializer in self. That is all it is required to do. It must do that before saying self for any other purpose.
In the Node extension, the convenience initializer is doing that; it is starting out by calling self.init(context:).
That is legal because Node is an NSManagedObject subclass (representing an entity), so it inherits that initializer:
https://developer.apple.com/documentation/coredata/nsmanagedobject/1640602-init
That's all there is to know. The fact that init(context:) is a convenience initializer is not interesting. It's an initializer of self, that's all that matters.
Was reading about JPA here. Two of the requirements of an Entity class are that
The class must not be declared final. No methods or persistent instance variables must be declared final.
The class must have a public or protected, no-argument constructor.
Persistent instance variables must be declared private, protected, or package-private.
Was curious to know why are these conditions required ?
The class must not be declared final. No methods or persistent instance variables must be declared final.
JPA implementations use proxies in front of your entities to manage for example: Lazy loading. As a final class cannot be extended, a proxy cannot be built.
Some implementations as Hibernate can persist final classes but it can affect performance more info.
The class must have a public or protected, no-argument constructor.
These kind of frameworks and others in order to create new objects use ```Class.newInstance()`` that is the reason why a no arg constructor is needed.
Persistent instance variables must be declared private, protected, or package-private.
Being only accesible through accessor or business methods allow interception in proxies.
The reasons are (at least some of them):
JPA provider needs to create instances of the entity dynamically. If class would contain the only constructor which takes arbitrary arguments, JPA provider cannot figure out values for those arguments. That's why it must has a no-arg constructor.
JPA implementations deal with persisting instances of your entities classes. that's why the class, methods and variables cannot be final.
Because you don't want access to the variables from outside directly, in order to keep encapsulation - this is an OOP reason. another reason is that many frameworks of persistence are having a getter/setter method to identify POJO "properties".
I have use the type dynamic, a new type in .NET 4.0.
I want to use a dynamic type because I want to use some types that in advance I don't know what type is, but I know that all this possible type has some common methods.
In my case, I am using self tracking entities in entity framework 4.0, and I know that all the entities has the methods markedXXX (to set the state of the entity).
Through the dynamic object that I created, I can access and set the properties of one of this entities, but when I try to execute the MarkedAsXXX method I get an exception that says that the object has not definied the method.
I would like to know how to access to this methods. Is it possible?
Because I have a function that can access to the original values and set this values to the current one, but I need to set the entity as Unchenged.
Thanks.
I want to use a dynamic type because I want to use some types that in advance I don't know what type is, but I know that all this possible type has some common methods.
That suggests you should create an interface with those common methods, and make all the relevant types implement the interface.
Through the dynamic object that I created, I can access and set the properties of one of this entities, but when I try to execute the MarkedAsXXX method I get an exception that says that the object has not defined the method.
It's possible that this is due to explicit interface implementation. If the types have those methods declared as public methods in the normal way, it should be fine.
If you really want to use dynamic typing with these types, is there some base interface which declares the MarkedAsXXX methods, which you could cast the objects to before calling those methods? (I'm not familiar with the entity framework, so I don't know the details of those methods.)
Basically, I would try to avoid dynamic typing unless you really need it, partly because of edge cases like this - but if explicit interface implementation is the cause, then casting to that interface should be fine.
If you define an interface to the dynamically generated classes you can call the methods without the hassle of reflection calling.
I watch the Core Data guides, and there are two way to obtain a new NSManagedObject instances.
- initWithEntity:insertIntoManagedObjectContext: of NSManagedObject class
+ insertnewObjectForEntityForName:inManagedObjectContext: of NSEntityDescription class
Are there any difference between both methods? Or, they just mean the same thing for obtaining a new NSManagedObject under any conditions.
Based on what it's said on the documentation, by using the class method from NSEntityDescription to instantiate the NSManagedObject it's possible to do it without declaring/importing its header. By setting the name of the class you will get back a "fully configured instance" of the object.
It's useful on early stages of development when things are changing constantly but it can be a risk factor since you don't get any compilation errors or warnings if you misspell the name of your class, since it's a string.
The method from NSManagedObject needs that the interface of the specific class imported to your file, and make it more robust against errors, since the compiler can check if that class exist.
For instance they will have the same result, they will return an instance of the specified class. Although the retain counts will be different:
- initWithEntity:insertIntoManagedObjectContext: (retain count == +1)
+ insertnewObjectForEntityForName:inManagedObjectContext: (retain count == 0)
Here it is the documentation
NSEntityDescription Class Reference (insertNewObjectForEntityForName:inManagedObjectContext:)
Return Value
A new, autoreleased, fully configured instance of the class for the entity named entityName. The instance has its entity description set and is inserted it into context.
Discussion
This method makes it easy for you to create instances of a given entity without worrying about the details of managed object creation.
The method is particularly useful on Mac OS X v10.4, as you can use it to create a new managed object without having to know the class used to represent the entity. This is especially beneficial early in the development life-cycle when classes and class names are volatile.
On Mac OS X v10.5 and later and on iOS, you can instead use initWithEntity:insertIntoManagedObjectContext: which returns an instance of the appropriate class for the entity.
NSManagedObject Class Reference (initWithEntity:insertIntoManagedObjectContext:)
Return Value
An initialized instance of the appropriate class for entity.
Discussion
NSManagedObject uses dynamic class generation to support the Objective-C 2 properties feature (see “Declared Properties”) by automatically creating a subclass of the class appropriate for entity.initWithEntity:insertIntoManagedObjectContext: therefore returns an instance of the appropriate class for entity. The dynamically-generated subclass will be based on the class specified by the entity, so specifying a custom class in your model will supersede the class passed to alloc.
If context is not nil, this method invokes [context insertObject:self] (which causes awakeFromInsert to be invoked).
You are discouraged from overriding this method—you should instead override awakeFromInsert and/or awakeFromFetch (if there is logic common to these methods, it should be factored into a third method which is invoked from both). If you do perform custom initialization in this method, you may cause problems with undo and redo operations.
In many applications, there is no need to subsequently assign a newly-created managed object to a particular store—see assignObject:toPersistentStore:. If your application has multiple stores and you do need to assign an object to a specific store, you should not do so in a managed object's initializer method. Such an assignment is controller- not model-level logic.
I'm trying to create core data application.
Some times when trying to save data, i'm seeing following error:
Error: NSInvalidArgumentException,
Reason: * -_referenceData64 only defined for abstract class. Define -[NSTemporaryObjectID_default _referenceData64]!,
Description: * -_referenceData64 only defined for abstract class. Define -[NSTemporaryObjectID_default _referenceData64]!
I didn't understand why this error is coming and how to avoid it. Can some one help me please.
Edit: The original answer below is technically correct but doesn't accurately describe the true source of the error. The runtime can't find the correct attribute but the reason it can't find it is because the entity exist in another managed object context. The OP probably never had a _referenceData64 attribute for any of his entities.
See: http://www.cocoadev.com/index.pl?TemporaryObjectIdsDoNotRespondToReferenceData
Original Answer:
You have a class that has an attribute _referenceData64. In the data model, that class is marked as "abstract'. Select the entity in data model editor and check the box below that says "abstract". If it is checked, then that is your problem.
An abstract entity is never instantiated. Unless is has a subclass, you can't actually set its attributes to any value. Abstract entities just exist to provide templates for subclasses.