PropertyDefinition :: supersetPath - Superset
Base collections are an ODABA specific extension, which is used to define subset relationships between collections. The collection referenced in base_path is considered as superset or base collection of the relationship. The type (or base type for weak-typed collections) of the base collection must be the same as the type of the relationship or must extend the type of the relationship (when the base collection is weak-typed).
Base collections allow defining an extendable or not extendable value domain for a collection, i.e. a superset for a given collection (or single reference). Thus, one can define e.g., that all members of a section in a company must be employees of the company, which might be a subset of all persons again. You may also cascade supersets, i.e. a referenced superset may have another superset etc. There are, however, some constellations, which must be treated with care (see subsequent notes).
When adding a new instance to the relationship, the system first tries to locate the instance in the base collection. When not yet existing, the instance will be created and added to the base collection automatically.
Typically, base collections are defined as extents, but a base collection may also refer to a relationship of the same or another instance (local collections). When referring to a local collection, the base_path has to begin with '.' followed by a traversal path beginning at the current instance.
In case of weak-typed relationships, instances of the collection can be looked up in the default extents for the current instance data type. The default extent is an extent that has got the same name as the as the data type. Defining default extents as base collections is expressed by '*' as extent name.
When no base collection is defined, the collection should be the owner of the instances (owning property) or a secondary inverse relationship. In this case, no base collection relationships are maintained.
Superset and subset relations can be defined for local collections as well as for extents. In contrast to extents, however, local collections cannot have more than one superset. It is also not possible to define special properties as distinct or complete for local collections explicitly.
By defining supersets (base collections) for relationships, subsets (derived collections) are defined implicitly. In order to keep superset/subset relations consistent, ODABA maintains subsets when the superset changes. Maintenance is not a problem, as long as the superset is a global collection (extent). In this case, removing an instance from the extent, which is also stored in the relationship's collection, the instance will be removed from the relationship collection.
Also for local supersets (base collection path begins with dot), instances removed from the superset are automatically removed from the subset, when being stored in the subset, too.
The other way around, instances inserted in the subset are automatically added to the superset, when not yet existing.
The situation becomes a bit more complex, when defining superset paths like " .a.c ", in which case the subset (current relationship) depends in instances in c , which is a collection in an instance stored in a . Hence, removing or changing the instance referenced in a will also change the superset c . Thus, removing or changing the instance referenced in a will remove all instances from the subset (current relationship).
When the superset path exceeds two relationships (e.g. .a.b.c ), changes in c will still affect the subset, but removing or changing an instance in b will not be recognized and the superset/subset relation may become inconsistent, in this case. Hence, it is sugested, not using superset paths with more than two relationships. Othewise, the application has to maintain the subset in case of changes in the middle relationship(s).
The property name may contain a property path that consists of a sequence of property names. Not allowed are operation paths or path properties, i.e. the property name must consist of identifiers separated by dots (.), only.
In order to pass no property name, an empty string ( String() ) has to be passed.
Implementation details
If the PropertyDefinition is a valid database property definition the function returns a string containing the property path for the base collection. It returns an empty string if no base collection is defined. If there is no valid database property definition, the function throws an exception.