Models - OpenSlides/OpenSlides GitHub Wiki

All models are defined in the models.yml. Models are grouped in collections. A specific model consists of fields, which can hold arbitrary values.

Saving null/undefined (Javascript), None (Python), ... into a field deleted the field, so there is no difference between the absence of a field and a null value.

• collection: E.g. motion. Holds all objects from the same type. Valid names must fully match ^([a-z]+|[a-z][a-z_]*[a-z])$
• id: Each model of a collection has a unique id. Valid ids must fully match [1-9][0-9]*
• field: A model has fields. Valid fields must fully match ^[a-z][a-z0-9_]*$
• fqid (full-qualified id): Identifies a specific model: <collection>/<id>
• fqfield: (full-qualified field): Identifies a specific field of a specific model: <collection>/<id>/<field>
• collectionfield: Identifies a "generic" field of a collection: <collection>/<field>

Some collections have a tree-ordering. The order is determined by two fields parent_id and weight. These fields might have different collection-specific names, but for this generic explanation we will keep these names.

Root elements have parent_id=0 and each model sharing the same parent_id are children of this parent. The weight orders the children of a parent with higher weights being lower/later. We have special requirements for weight: The weights are chosen as one would traverse the tree in preorder, having only even weights (0, 2, 4, 6, ...). Additionally, every tree-ordered models have a calculated field level representing the depth of each item.

Example (parenthesis: (weight, level)):

A (0, 0)
  -A1 (2, 1)
  -A2 (4, 1)
    -A2.1 (6, 2)
  -A3 (8, 1)
B (10, 0)
  -B1 (12, 1)

The advantage is the displaying in the client: Sorting all items by weight and displaying a flat list with each indentations linear to level results in the tree for the user. Some notes for the weight field:

• sort action (actions which reorder the tree with a new order provided by the client) currently can only sort the whole tree (see the tree sort mixin)
• adding a new element as a child to a parent can be done by setting the parent_id accordingly and setting weight=parent.weight+1. This results in these elements being always the first child. This has the advantage, that the last child must not be searched during the creating to get the last child's weight. When adding multiple new elements, they get the same weight. This is ok since the client always additionally sorts by id, so the order is still defined. Note: if new elements should come last, one can reverse the weights having the highest item the highest weight and reverse the sorting in the client.

When does this doesn't work:

• Removing one element (E.g. deleting of A2 in the example): The child (A2.1) will be moved to the root, which is ok. But A3 now looks like being a child of A2 instead of A (the parent_id relation is still ok).

How to fix this: The client has to sort the tree, or the backend must recalculate all weights.