Limitations

While the architecture specs define high-level requirements for this abstract and generic tool we might want to disallow certain actions, concepts, etc. in order to keep it sane.

Attribute Definitions

Changing the data type of an attribute

While such a change might work in certain directions (e.g. int to float or anything to str) it might not in others. Providing a single default value for all entities in a schema might also not be the desired behavior.

Therefore, we will not support this. Type conversions should be performed by a client (manually or automated) and results stored in a new attribute.

Changing an attribute definition from a single value to a list of values (and vice versa)

While the transition from a single value to a list is unambiguous and might be easy to implement, the same is not true for the other direction. In addition, both changes would constitute an API change, that is not backwards compatible.

Therefore, we will not allow this. However, users will be able to work around this limitation by

• adding a new attribute of the desired type,
• deleting the old attribute and
• renaming the new attribute to the old attribute's name

Unique list of values

Attribute definitions allow setting a unique flag to enforce that the values of an attribute are unique for a schema. For multi-valued attributed, such a constraint is difficult to implement and does not make much sense.

Therefore, the unique constraint will only apply to single-value attributes. However, values in a multi-valued attribute are prevented from being duplicated.

Change Requests

One exclusive request per entity/attribute

In the architecture specification it said:

It should be possible to prevent the submission of change for a value, for which another pending review exists.

After careful deliberation this limitation might be counter-intuitive for users. Therefore, it was decided to drop this limitation.