What I see
Info:
Model errors:
MVH201 Derivation expression specified for non-derived attribute (Issue.Job) [Issue.Job]
I'm wondering if this was intended to be
MVH201 Derivation expression specified for non-derived attribute
("class.attribute") ["Derivation expression"]
If you at first had the attribute as derived - and then in a subclass added an override for it (derivation expressions on the subclass) - but then made the original attribute persistent again (none derived) -> bam!
MDriven will warn you that the derivation expression in the subclass is there - but it has no effect.
Related
I've read Subclassing NSManagedObject with swift 3 and Xcode 8 beta and read this great tutorial. Still have questions on some points.
The similarities are:
I can customize both classes however I like.
I can add new attributes or remove or rename attributes. ie for category/extension it will get updated upon a new build (in the derived data), and in case of manual/none it will leave the class file intact and update the extension in the file navigation ie I won't end up with a duplicate file. This is all handled by Xcode because they are marked with a preprocessor #NSManaged
Dumping something like #NSManaged public var name: String? straight into an existing NSManagedObject subclass is not allowed. I tried to do entity.name = "John" but I got the following error: reason: '-[SomeEntity setName:]: unrecognized selector sent to instance 0x60400009b120'. I believe that's reasonable. I think without using the Core Data Model Editor the setter/getter accessor methods are not created.
The differences are:
For Category/Extension you just need to create the class yourself and add any extra functions/properties you need.
For Category/Extension the attributes are created in derived data which is enough. Because you never need to see that file. Its existence is enough to get things working.
And specifically in the context of making changes to your NSManaged properties:
Changing property type, e.g. NSDate to Date is allowed only for Manual/None . Example here
Changing optionality of a type, e.g. String? to String is allowed only for Manual/None. Example here
Changing a property access level, e.g. from public to private is allowed only for Manual/None. Example here
Having that said there is significant difference if I choose Manual/None codegen and but don't select 'create NSManagedObject subclass'. In that case I have start writing all the code myself (subclass from NSManagedObject and write NSManaged for every property)...or if I don't write all that code myself then I can still access/set fields using KVC which is awkward!
In a nutshell I'm just trying to figure out the full extent of capabilities that I can get from using Manual/None.
Question: Aside from the 9 notes which I need to know if I have validated correctly, an important question would be: how does me changing NSDate to Date or optional to non-optional not break the mappings between my NSManagedObject class and my object graph all while changing an NSDate property to String does break!! Does this have something to do with things that have guaranteed casting between Swift and Objective-C ie things that can be casted through as — without ? or !?
To address each of your notes and considering the cases where codegen is set to Manual/None and Category/Extension:
Yes, in either case you can customise the classes however you like (within limits - for example, the class must be a subclass - directly or indirectly - of NSManagedObject).
Correct. You can add, amend or delete attributes in the model editor. In the Category/Extension case, the relevant changes will be made automatically. In the Manual/None case, you can either manually update the Extension (or the class file) or you can redo the "create NSManagedObject subclass" which will update the Extension with the amended attribute details. If you do not do this, Xcode will not recognise the new attribute details and will not provide code completion for them (nor will it successfully compile if you try to override code completion). But unlike what you think this has nothing to do with the properties being marked as #NSManaged.
Correct. Adding an #NSManaged property to the class definition (or Extension) is enough to tell Xcode that the property exists (so you can reference them in code) but does not create the corresponding getter/setter. So your code will crash.
Yes, for Category/Extension just create and tailor the class file as you require.
Yes, for Category/Extension the properties are declared in the automatically created Extension file in Derived Data.
Changing the property definition in any way - from Date to NSDate, or marking it private, or whatever - can only be done in the Manual/None case because the Extension file in Derived Data is overwritten with each new build so any changes are lost.
Ditto
Ditto
Correct. You could write your app without ever creating separate NSManagedObject subclasses (automatically or manually), if you use KVC to access the properties.
As to your final point: you cannot arbitrarily change the type of the property definition: the type specified in the model editor must correspond to the type specified in the property definition. You can switch between optional and non-optional versions of the same type, and you can switch between Date and NSDate etc, but switching from Date to String will not work. I suspect you are correct that this is due to the bridging between Swift value type and the corresponding Objective-C reference type using as. See here.
in the OPAL framework, is it possible to manually create an annotated method?
I currently have the following code:
Method(0, "signaturePolymorphicMethod",
MethodDescriptor(ObjectType("java/lang/Object"), VoidType), Seq())
and I want to add the annotation
#java.lang.invoke.MethodHandle$PolymorphicSignature
to this method. How can I do this?
Annotations are generally stored using the JVM's general "Attributes" mechanism.
In this case the annotation is a non-public inner class of MethodHandle with the "Runtime Retention Policy". Hence, to mark a method as having a "Polymorphic Signature" it is necessary to add the RuntimeVisibibleAnnotations_Attribute to the respective method's attributes table. However, given that the visibility of the annotation is limited to the java.lang.invoke package this is (in this specific case) probably rarely useful. Nevertheless, it is possible to query methods in the respective package
This came up in another question (kindly answered by meronix) but I curious to learn a little more about what is going on here, is this a LLVM/Clang issue, or are the two statements different in someway.
I know I can fix this by adding (See below), so more curious than anything ...
The two statements are different. A property can only be used if the type of the lvalue declares the property. This is because the getter and setter for the property might be non-obvious (often the case with boolean properties, where the getter is explicitly set to isSomething.) The compiler cannot infer that without strong type info.
The [lvalue message] syntax, however, has no such ambiguity, so the compiler allows it. Since the type of the lvalue is id, any known message can be sent to it without a compiler warning. The compiler will only warn if two signatures correspond to the same selector (for instance, one class has - (UIWindow *)window and another has - (int)window.)
The UIApplicationDelegate protocol defines a window property, so when you explicitly type your object as id <UIApplicationDelegate>, the compiler knows about the property and can use it.
I have a case that is very similar to this, but following the advice in the answers does not solve my problem.
I have a ViewModel in an MVC 2 application that contains another class. I have a controller that contains a strongly typed create method:
[Authorize]
[HttpPost]
public ActionResult Create(AIViewModel ai)
{
}
When I look at the ModelState when I enter the Create method, the data indicates that the simple properties that are present within the AIViewModel class are bound correctly, while the complex type that is in there fails with the following error message:
"The parameter conversion from type 'System.String' to type 'xyz' failed because no type converter can convert between these types."
If I look at the value that it tries to bind, it has indeed the System.String type and value "Create". Anybody has a clue on what I could be doing wrong?
UPDATE: I have found the problem: The property is called Action, which somehow fools the the modelbinder. Renaming the property solved the issue.
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.