I am building an app using Swift2 and Realm to persist the data. The data relationships could be described as parent-to-child-to-grandchild objects. Each object has it's own subclass written with the same format. I am getting the runtime error "RLMObject subclasses cannot be nested within other declarations. Please move _TtCC12 ... to global scope.'" on the grandchild object. Any suggestions?
The error message is telling you that the declarations of your RealmSwift.Object subclasses must be at the outermost scope, and cannot be nested within other class or struct declarations, or function definitions.
Related
As updating business network could break your APIs and You may not able to fetch old data. We are looking for generic guidelines about what we should take care before updating business network and deploying using composer.
We will include this into the docs for the release next week...
Model Compatability
Introduction
Composer models are expected to change and evolve over time. However some care and discipline must be applied when making model changes to ensure that existing instances are still valid with respect to the new model.
A model M' is compatible with model M if instances created with model M are valid with respect to model M'. If the instances are valid, then they may be deserialized using the Serializer.
Terminology
The following terms are used throughout this document:
Class : the declaration of the structure of an asset, participant, transaction, concept or event
Instance : an instance of a class, for example if org.example.Vehicle is an asset (class), then org.example.Vehicle#ABC123 is an instance of an org.acme.Vehicle
Property : a member (or field) defined by a class, including a relationship. For example the class org.example.Vehicle may have a property called model of type string.
A class (the asset SampleAsset):
```
namespace org.acme.sample
asset SampleAsset identified by assetId {
o String assetId
--> SampleParticipant owner
o String value
}
```
An instance of the class:
{
"$class": "org.acme.sample.SampleAsset",
"assetId": "assetId:6463",
"owner": "resource:org.acme.sample.SampleParticipant#participantId:8091",
"value": "secret plant frequently ruler"
}
Evolution of Namespaces
A new class may be added to a namespace without breaking compatibility with pre-existing instances.
Evolution of Classes
This section describes the effects of changes to the declaration of a class and its properties on pre-existing instances.
Renaming
Renaming a class will break compatability with any pre-existing instances of the class, or relationships to the class.
abstract Classes
If a class that was not declared abstract is changed to be declared abstract, then attempts to create new instances of that class will throw an error at runtime; such a change is therefore not recommended for widely distributed classes.
Changing a class that is declared abstract to no longer be declared abstract does not break compatibility with pre-existing instances.
Superclasses
An error is thrown at load time if a class would be a superclass of itself. Changes to the class hierarchy that could result in such a circularity when instances are loaded are not recommended for widely distributed classes.
Changing the direct superclass of a class type will not break compatibility with pre-existing instances, provided that the total set of superclasses of the class type loses no properties.
If a change to the direct superclass results in any class no longer being a superclass respectively, then errors may result if pre-existing instances have relationships to the modified class. Such changes are not recommended for widely distributed classes.
Class Properties
No incompatibility with pre-existing instances is caused by adding a property to a class if the property is either declared as optional or is assigned a default value. Adding new properties that are neither optional nor have a default will break compatability with any pre-existing instances of the class.
Changing the cardinality of a property (changing an array [] to a non-array or vice-a-versa) will break compatability with any pre-existing instances of the class.
Deleting a property from a class will break compatibility with any pre-existing instances that reference this field.
Changing the type of a property may cause an error if the property is used by a pre-existing instance.
Changing the validation expression of a property may cause an error if the property is used by a pre-existing instance.
Properties that are relationships follow the same rules as for other types.
Evolution of Enums
Adding or reordering constants in an enum type will not break compatibility with pre-existing instances.
If a pre-existing instance attempts to access an enum constant that no longer exists, an error will occur. Therefore such a change is not recommended for widely distributed enums.
In all other respects, the model evolutions rules for enums are identical to those for classes.
What is the difference between Class Module(.cls) and . Module(.bas) in Visual Basic ?
A Module(.bas) has methods and variables that can be used globally in your program and there is only a single instance of the data (similar to a Static method or field in C#). A Class Module(.cls) has properties and methods that usually can only be accessed when the object is instantiated, but can have multiple copies, each with differing data.
From MSDN: Visual Basic Concepts:
Classes differ from standard modules in the way their data is stored.
There is never more than one copy of a standard module’s data. This
means that when one part of your program changes a public variable in
a standard module, and another part of your program subsequently reads
that variable, it will get the same value.
Class module data, on the other hand, exists separately for each
instance of the class.
And from Devx.com: Class Module(.cls) vs. Module(.bas):
Deciding between a standard module and a class module is not a
decision based on performance, but one of design. The main difference
between the two is in the way that they handle data. A standard module
stores only one copy of the data. A class module encapsulates the data
within each instance of the class. That is, for each instance of the
class, the data exists separately.
The other main difference is the scope of variables and procedures
within the module. In general, any variables and procedures declared
as Public within a standard module are visible anywhere in the project
or external programs if the standard module is in a component.
Variables and procedures declared as Public within a class module can
only be seen through a reference to an instance of the class module.
The lifetime of data and procedures stored within a module is affected
by which type of module is used. The lifetime of the data and
procedures in a class module is defined by the lifetime of the object.
So data and procedures are available only if a reference to the object
exists. Data and procedures declared within standard modules are
available for the lifetime of the program.
Therefore, to answer your question, if you are writing a function that
you want available throughout the lifetime of the program and visible
to all code in the application, then place the function within a
standard module.
If the code is needed for lifetime of the program and is visible to all code in the application, then place the function within a standard module.
A standard module stores only one copy of the data. A class module encapsulates the data within each instance of the class. That is, for each instance of the class, the data exists separately.
In general, any variables and procedures declared as Public within a standard module are visible anywhere in the project.
Variables and procedures declared as Public within a class module can only be seen through a reference to an instance of the class module.
The lifetime of data and procedures stored within a module is affected by which type of module is used. The lifetime of the data and procedures in a class module is defined by the lifetime of the object. So data and procedures are available only if a reference to the object exists. Data and procedures declared within standard modules are available for the lifetime of the program.
Sandy Metz says (POODR book, page 26):
Because it is possible to wrap every instance variable in a method and to therefore treat any variable as if it's just another object, the distinction between data and a regular object begins to disappear.
I am not sure if I understand what she is explaining. When we define the accessors, we are wrapping the instance variables (data) on a method but methods are not objects. So what does she mean when she says that we can treat variables as if they're just another object?
The primary difference between data and objects is behaviour. Objects can modify their internal state without changing their interfaces, while data are static structures.
When we wrap data access within a method, we get the same benefits of an object - the interface remains static to consumers even if the underlying data structure needs to change.
From what I am reading, a delegate instance is always defined with a class as an input or inside a class.
Why can't I define a delegate instance independently?
A delegate is a type, and you can define it at namespace scope (including the global namespace).
Since delegates are reference types, delegate instances always are placed on the managed (garbage collected) heap. Delegate instances can be created with the gcnew operator, the Delegate::CreateDelegate method, or using stack semantics syntax (C++/CLI only).
A reference variable of delegate type (including stack semantics syntax variables which wrap a permanently-bound reference, an instance on the heap, and an automatic call to IDisposable::Dispose) can exist as an instance or static member of a managed type, an automatic local variable, a static local variable, or (in C++/CLI) as a global (namespace scope) variable.
I have a Core Data model where I have an entity A, which is an abstract. Entities B, C, and D inherit from entity A. There are several properties defined in entity A which are used by B, C, and D.
I would like to leverage this inheritance in my model code. In addition to properties, I am wondering if I can add methods to entity A, which are implemented in it's sub-entities.
For example:
I add a method to the interface for entity A which returns a value and takes one argument
I add implementations of this method to A, B, C, D
Then, I call executeFetchRequest: to retrieve all instances of B
I call the method on the objects retrieved, which should call the implementation of the method contained in B's implementation
I have tried this, but when calling the method, I receive:
[NSManagedObject methodName:]:
unrecognized selector sent to instance
I presume this is because the objects returned by executeFetchRequest: are proxy objects of some sort.
Is there any way to leverage inheritance using subclassed NSManagedObjects?
I would really like to be able to do this, otherwise my model code would be responsible for determining what type of NSManagedObject it's dealing with and perform special logic according to the type, which is undesirable.
Any help is appreciated, thanks in advance.
It should work. The objects returned by executeFetchRequest: are real instances of NSManagedObjects (or subclasses thereof.)
The steps to use custom classes in CoreData are as follows. Say you have entities A and B, where B inherits from A.
Then you need two custom classes as
#interface A:NSManagedObject{
}
-(void)someMethod:(NSString*)a;
#end;
#interface B:A{
}
-(void)someMethod:(NSString*)a;
#end;
Then set them in the XCode data modeler as shown:
This way, the CoreData automatically assigns the correct class to the NSManagedObject when it is fetched from the database.
If you're getting that exception, it means Core Data is not using your custom class. The key here is NSManagedObject -- that's the object Core Data created for the objects in your data store.
If you haven't already, you'll need to create a class that inherits from NSManagedObject, add your custom methods there, and then set entity A to use your custom class in the object model tool. If entities B, C, D, etc. have specific behaviors, you should subclass the class you created for entity A and assign those entities to use the subclasses too.
Essentially, you have a parallel hierarchy: one hierarchy of entities, and another of classes. You'll likely end up with entity X and class X for each entity in your object model.
After trying lots of solution calling isMemberOfClass on my NSManagedObject subclass before trying to use my custom method made the trick.
[thing isMemberOfClass:[Thing class]];
[thing customMethod]; //was getting unrecognized selector sent to instance here before
I had this same error for the same underlying reason, but it came about in a different situation and a different cure. Your suggestion helped me a lot!
Originally I had created my class implementing my entry by hand. I didn't know there was an Xcode menu for this. I think the link was never there! So it wasn't until I had added and began testing the new custom methods (not setter/getters) that I started to get the error.
My solution was to change the name of my class, have Xcode re-create the class for my entry via Editor->Create NS Mangage Object.... Then cut and paste in the old code into the new class. No difference in code!
Xcode seems to have some kind of internal link that is not apparent in the code.