A property of type Set must be of the sub-type Biskits. The following must then be specified:

 

exp_bakerySetDef

 

Name

Meaning

Sub-type

The type of data stored by the property represented by this definition.The choice is Biskit or String. String is used when dealing with Tags.

Sorted

Indicates whether the contents of the Set are sorted or not.

BiskitDef

Specifies the type of Biskit the set will contain.

Component

Indicates whether the Biskit value is stored as a reference to a Biskit stored somewhere else, or if its properties are stored directly as a component of its owning Biskit. Normally only used for static properties.

Biskit Property Type

One to Many, Many to Many Persisted, Many To Many Unpersisted, To Many, explained below.

Reference Deletion Option

Cascade or Null. Cascade Indicates that the children need to be deleted when the parent is.

Inverse Property

This is the property on the Set Biskit which will point back to the parent Biskit

Biskit Property Type

Value

Meaning

One To Many

Indicates the set contains "child" Biskits that will all reference this Biskit as the "parent" in a Many To One Biskit property.

 

With this value of Biskit Property Type, we must also specify the Inverse Property Name that is the name of the child's property that reference the parent.

Many To Many Persisted

This Set represents the persisted half of a Many To Many property. See Many To Many Properties.

Many To Many Unpersisted

This Set represents the unpersisted half of a Many To Many property. See Many To Many Properties.

To Many

This Set is a collection of Biskits, but the Biskits we contain do not reference us in any way.

 

Currently Many to Many (in all its forms) is not implemented for dynamic Set properties.

Many To Many Properties

Suppose a user can be associated with any number of projects, and a project can have any number of users associated with it. This means there will be a collection of projects stored in a property on each user, and also a collection of users stored in a property on each project. Both sides of this relationship are known as Many To Many properties.

 

If a project is a member of a user's projects, then that same user would be a member of that same project's users and vice versa. This means it is not necessary to save both sides of this relationship to the database because of this symmetry. However, there are some occasions when it is necessary to know which side is persisted, and so one half is known as a Many To Many Persisted, and the other half is known as Many To Many Unpersisted.