Complex types in v2 odata model and cds-maven-plugin

[former_member391444]

Dear Colleagues,

I wanted to add an array attribute to one of my v2 oData model entity sets, something that should roughly look like that in the tree representation:

ExtensionField
   ID: String;
   Name: String;
   ....
   PermittedActions: // (the array I am adding)
       Name: String;
       Description: String;

Here's what I've done in CDS in order to achieve that:

1. Introduced a new complex type

type Actions : many {
  Name: String(32);
  Text: String(64);
}

2. Added that new field to the extension field entity set definition:

entity ExtensionField as projection on PendingExtensionFields {
  *,
  null as Actions         : Actions
  ...
} 

That seems to do the trick in terms of creating the odata model; cds build runs smoothly and it seems to create exactly the entity set I want:

      <ComplexType Name="mdo_Actions">
        <Property Name="Name" Type="Edm.String" MaxLength="32"/>
        <Property Name="Text" Type="Edm.String" MaxLength="64"/>
      </ComplexType>
      ....
      <EntityType Name="ExtensionFields">
        <Key>
          <PropertyRef Name="ObjectType"/>
          ...
        </Key>
       ...
        <Property Name="Actions" Type="Collection(mdo.manageBOTypes.mdo_Actions)" Nullable="false"/>
      </EntityType>

But the good news end here unfortunately. Once I try to build the whole java backend, it crashes, during the plugin
cds-maven-plugin tries to create the necessary POJO classes.
I wouldn't want to go very deep into details here, the generated POJOs relate to other ones that are not properly
created and so the build fails

Did someone maybe have some similar experience already?

Thank you and best regards,

Kirill

[Ivan-Mirisola]

Hi kirill.chekhter,

Have you tried the following:

entity ExtensionField {
  key ID  : String;
  Name    : String;
  MyActions : mdo_Actions ;
}

type mdo_Actions : many {
  Name    : String(32);
  Text    : String(64);
}

service MyService {
  entity ExtensionFields as projection on ExtensionField;
};<br>

It seems to produce the same output metadata as you expect. The only difference is that

NOTE: Be careful with the name Actions here. An OData service may have implemented actions which differ from entity fields. In Java it should work as it is case-sensitive. But, I would highly recommend you to avoid that name so others may understand what you are trying to code in CDS.

NOTE2: You can't make the array type 'mdo_Actions' to be null. Therefore you must guarantee to supply it with default values in case your UI doesn't fill it. On the other hand, fields on 'mdo_Actions' can have null values.

NOTE3: If on the EDMX, the property 'MyActions' doesn't come up as a Collection of 'mdo_Actions', then check which the version of OData being implemented in Java - it should be V4.

Best regards,
Ivan

[former_member391444]

Hi ivan.mirisola,

thank you for your response. I cannot do it quite according to your proposal, because the oData entity set is transient, and my idea was to only add the permitted actions property on the odata level and do not litter the DB table unnecessarily.

Note1: the name is actually PermittedActions and it indeed refers to a subset of all actions defined for the given entity instance (depending on the instance, not all of them can be allowed)

Note2: Because the entity is transient, defining the field as null is not a big deal, I am going to always rewrite it in the corresponding @On(event=CqnService.EVENT_READ) CAP hook method.

Note3: The oData version we use is v2, however I don't see why v2 shouldn't work. CAP also supports v2 and it worked just fine until now. Aside from that, according to the oData documentation array attributes do not seem to be forbidden.

Best regards, Kirill.