Weak-typed collections

This option marks a collection as weak-typed collection, which can store instances of different data types. Before creating a new instance for a weak-typed collection in an application, one has to set the correct type (Property::setType()).

Defining base collections for a weak-typed collection requires a weak-typed collections, again, but one may derive several typed collections from a weak-typed collection.

Typically, one refers to weak-typed collections in inverse relationships. When an inverse relationship, which is a weak-typed collection, is marked as secondary, instances stored in the weak typed collection are the lowest instances, which refer to the inverse reference and do not have a shared base instance referring to the inverse reference as well.

Weak-typed collections marked as primary will contain the instances as being added to the collection, i.e. one may add a Person or a Student (but not both), also when the Student inherits from Person as shared base structure. In this case the application is responsible to add and remove the proper instances. Adding a Person to the collection and removing a Student, however, may cause problems deleting the inverse reference and should be avoided by the application.

Some special checking and auto-correction rules have been implemented for weak-typed relationships:

1. When defining relationships in a structure A with inverse references in related structures S1, ... Sn, this is no problem. But defining an exclusive specialization A1 of A , all inverse relationships in related structures S1, ... Sn for relationships in A must be set to weak-typed. This will be done automatically when checking the specialization (A1 in this case).
2. When a relationship is a weak typed collection and defines a real base collection (not '*'), the base collection must be weak-typed as well and the relationship type must inherit from the base collection type.
3. Usually, it is checked, whether inverse references are relationships in related structure definitions and an error will be displayed, if not. When, however, defining A1 as shared specialization of A with an inverse (type) reference (e.g. relationship "a_ref") in A, which refers to specialized instances of A, checking becomes more difficult. In this case, "a_ref" would refer to the base type in derived structures, which must have the same name for all specializations. The Type is, of course, A, and by default the name of the base structure should be A as well. When using the type name also as base structure member name, no inverse reference will be checked for "a_ref", which would result in an error otherwise.

You may also store share-base instances in a weak typed collection (e.g. an Employee, which might be share-base on Person). Than it makes a difference, whether storing the employee "Miller" or the person "Miller", since reading the instance will return either the person or the employee depending on what has been stored.

When referring to share-base instances in a weak-typed collection, it is suggested to define an identifying key for the collection. If there is a problem with a unique key, you may always use an __AUTOIDENT key.

When referring to shared-based instances in a weak-typed collection with an identity order (LOID), problems may appear, when using such a weak-typed collection as base collection. In this case, deleting instances from a base collection may cause problems.