Accessing overloaded object spaces
When opening a property handle for an extent in an overloaded object space, an overload property will be created, which internally refers to extent property handles for all extents in overloaded object spaces. Internally, collections of all extents are merged by giving highest priority to the extent of the last overloaded object space.
Subordinated property handles for local collections are also opened as overloaded property handles by extending or overloading collections from all instances located in overloaded object spaces.
Access functions for overloaded collections behave slightly different from accessing ordinary collections.
- Changing access key for extended collections is supported for unique keys (except __IDENTITY key), only. Changing access key may change the content of the collection.
- Extended collections do not immediately react on changes made on involved collection by other property handles. In order to update an extended collection, Property::reopen() has to be called.
- Updated instances are stored on top property handle (localizing), always. This may cause creating instances for parent property handles, too.
- Deleting or removing an instance is possible only, when this instance is stored in top object space. When the instance is stored in top object space, but also in another object space of the overload list, the instance in the topmost object space containing the instance becomes active, i.e. the overloading instance is deleted, only. When not existing in another object space, the instance is removed from the extended collection.
- Renaming instances (changing key attributes) has an effect in top object space, only. I.e. overloaded instances in subsequent object spaces remain unchanged.
When a function implementation i01 of function read in class Person of the last object space has been updated and class person does not yet exit in top object space, a class instance Person with a function instance read is automatically created in the top object space before adding the updated implementation instance i01.
When updating instances stored in an overloaded database, those are copied to top object handle, i.e. data is localized. This action has two relevant side effects.
When the instance to be localized is not a global instance but owned by another instance, which is not an instance of the top object handle, the owner instance is localized, too. This process continues until reaching the topmost parent instance.
When localizing an instance, instances for protected collection properties are copied, when the collection is an owning collection. When the collection is not owning, instance references by name (primary key) are created, which will be resolved when referenced instances are localized. In this case, the collection is localized, but the instances are not. When the collection has got more than one index, name references are created for all indexes.
Collection properties marked as private or public are never copied. This is typical the case for secondary (inverse) relationships.