CUBA.USER vs CUBA.SYSTEM and their connection to what we actually need

[stefanoborini]

There are a few things that I am not sold for with CUBA.SYSTEM/CUBA.USER.

Ok, established that we have two types of properties:

• fixed properties: lowercase letters. cannot be changed, they are stored on the class. Example: definition, models, variables.
• variable properties: qualified CUBA keys. Can be changed, they are stored in data. Example: CUBA.MATERIAL.

This said, we have cases where things should be fixed, but stored in data. For these cases, we have strange hacks and special cases. Examples are UUID/uuid. Strangely enough, while we have CUBA.UUID and I would expect this information to hold the generated uuid of the object, this value is actually stored in _uid, and CUBA.UUID in data is never populated. I suspect this is an error.

Currently, in the file we also have the following weirdness: ENGINE/ENGINE_FEATURE, ENGINE_FEATURE/PHYSICS_EQUATION and ENGINE_FEATURE/COMPUTATIONAL_METHOD they are marked as SYSTEM. this makes little sense to me, and I suspect they were meant for other reasons, maybe before the time of the same fixed properties? In fact, if you look at the generated files (EngineFeature) they make no sense.

I suspect the problem arises from mixing together different unrelated degrees of freedom:

1. How to generate the property value (computed/passed)
2. where to store the value (on class/in data)
3. if the property can be modified or not. (e.g. has a setter)

[stefanoborini]

@mehdisadeghi @ahashibon I need your feedback on this one as soon as possible. Thanks.

[ahashibon]

first regarding CUBA.SYSTEM: they mean that a value is set at "run time" i.e., upon creation and should not be changed later, they become part of the (meta-)data of the entity. The UUID is the prototypical example for this. Whether this is achieved by not having a setter or any other implementation, is not relevant for the metadata itself.

[stefanoborini]

@ahashibon Ok, so it means "read only" which is the same thing one technically achieves with a fixed property (as far as I can see they are also read only, and set at "run time", like models, definition and so on.). The only difference is that UUID is stored in the DataContainer, while fixed properties aren't.

My point is that UUID, from the technical point of view, is a fixed property that just happens to be stored in a different place (e.g. in the DataContainer, instead of the class) and have an associated CUBA key.

[ahashibon]

My point is that UUID, from the technical point of view, is a fixed property that just happens to be stored in a different place (e.g. in the DataContainer, instead of the class) and have an associated CUBA key.

not exactly, in principle all data should be stored in the data container (at least conceptually). We should not "contaminate" the metadata with implementation details.

moreover, the value of the uuid is not fixed on the metadatsa level, like models, etc. in a sense, UUID is a readonly property of the instance of the class, which models is a prtotected property of the class it self. Hope I did not mix the terms..

[stefanoborini]

A few questions:

• with metadata you mean anything that does not go in DataContainer (and thus ends up on the class attributes)?
• If UUID is not fixed, but readonly, how are you supposed to modify it without a setter (being readonly)? Also why would you want to modify the UUID? It's system assigned for uniqueness, and it should not be touched unless we are recreating from disk, which is a completely different use case with a different setting strategy

[stefanoborini]

Specified meaning of USER/SYSTEM in pull request #112