CUBA Platform REST API Anomalies

Support
#1

Hi,
working on this topic we found several discrepancies. Whereas all them are not stoppers for us, their existence could break down the contract and lead to errors on a one unlucky day.

  1. Being a kind of ephemeral entity by nature, sys$QueryResult is still an entity, so /rest/v2/entities/sys$QueryResult should make sense, but actually this request produces 500 error because QueryResult cannot be cast to an Entity

  2. We use Metadata API to generate and validate existing domain entities model. CUBA uses several enums which don’t implement EnumClass, namely com.haulmont.cuba.core.global.ClientType and com.haulmont.cuba.core.app.dynamicattributes.PropertyType. They are not present in the enum list, and we are unable to process corresponding attributes in entities (sys$CategoryAttribute, sec$SessionLogEntry, sec$UserSetting)

  3. And the last one - sec$EntityLog references to the type sec$EntityLogAttr which is not listed in the entity list at /rest/v2/metadata/entities/

Regards,
Ilia.

#3

Hi, @ilya.rodionov

  1. yes, it is a problem. An issue in YouTrack: PL-10538
  2. the EnumClass interface is used only for attributes that should be stored in a database. Moreover entities model will be generated after implementation of this issue: PL-9387
  3. could you specify the problem? It is not clear for me now.

Regards,
Daniil.

#5

Hello, Daniil.

  1. Ok, thank you.

  2. According metadata this is not a transient fields, for example - dataType in CategoryAttribute:

{
            "name": "dataType",
            "attributeType": "ENUM",
            "type": "com.haulmont.cuba.core.app.dynamicattributes.PropertyType",
            "cardinality": "NONE",
            "mandatory": false,
            "readOnly": false,
            "description": "Тип",
            "persistent": true,
            "transient": false
        },

Actually it’s defined as a String field, but both getter and setter use PropertyType (hence metadata says it’s a ENUM, I suppose)

  1. There is no mention for sec$EntityLogAttr as a an entity in the response here /rest/v2/metadata/entities/, whereas there is a column attribute in sec$EntityLog of that type):
    {
        "entityName": "sec$EntityLog",
        "properties": [
...
            {
                "name": "attributes",
                "attributeType": "ASSOCIATION",
                "type": "sec$EntityLogAttr",
                "cardinality": "ONE_TO_MANY",
                "mandatory": false,
                "readOnly": false,
                "description": "Attributes",
                "persistent": false,
                "transient": true
            },

Regards,
Ilia.

#6
  1. Yes, I agree that there is some inconsistency. We will discuss it.
  2. EntityLogAttr is the system level entity. Entities of the such type are not listed by design.
#7

Daniil,
thank you,

  1. I see. And do you believe there is good grounds to use such system level entities as an attrubute type? Can it be used in real life? Might it be more logical not to expose the attribute named attributes et all (as a variant)?
#8
  1. We’ve created an issue: YouTrack.
  2. We cannot use only “public” entities. To get access to such entities we suggest that you create a service and expose it.
#9

Ok,
thank you a lot.

  1. Actually we don’t need it, we are just generating C# model by Metadata service automatically and have got an error due the absence of this entity whereas the Metadata sevice is still referencing to it from other entites definition as I reported. Now we just ignore that attribute atturbutes which we can’t use but it’s a sort of WA anyway.

Regards,
Ilia.