Using enums not just as types but also as references for constants

[pepl]

Dear CAP team,

I would like to come with an additional proposal for this amazing framework.

So we have enums right now:

type Rating : Integer enum {
  Best  = 5;
  Good  = 4;
  Avg   = 3;
  Poor  = 2;
  Worst = 1;
}

which we can use as a type and it's already great.

entity Reviews {
  key ID   : UUID;
  rating   : Rating;
}<br>

However what could be really cool if we could use also those values as constants in our model.

Just for example

view BestReviews as select from Reviews where rating = Rating.Best

or even like that

entity as select from SapEvents {
  Events.SAP as source,
...
} union all select from NonSapEvents {
  Events.NON_SAP as source
}


type Events : Integer enum {
  SAP = 1;
  NON_SAP = 2;
} 

This way we can avoid of hardcoded values in our models in constant fields, where and joins conditions and navigation paths. It will help to refactor code also quickly and will help to search for references in the code faster.

What do you think?

Thanks!

[pepl]

david.kunz2 what do you think of this approach? Thanks!

[david_kunz2]

Hi pepl.booking ,

That's a really nice idea, let's ask the compiler colleagues, hans-joachim.both what's your take on that?

Best regards,
David

[steffen_weinstock]

We'll take this as a feature request and discuss it.

[former_member628556]

For a unique name resolution, using these constants would need to be written as Events:SAP or Events#SAP. Sometimes (if the type is known), we could even allow a short form like

entity as select from SapEvents {
  #SAP as source: Events,
...
} union all select from NonSapEvents {
  #NON_SAP as source: Events
}


type Events : Integer enum {
  SAP = 1;
  NON_SAP = 2;
} 

(and probably looking somehow like { ref: [ "Events", "SAP" ], const: true } in the CSN.

Also fine?

[pepl]

Well. From two proposals I would suggest to use hash better, because colon is already used to type declaration and as a parameter reference.

But why not dot? In this case enum is like a context for unique values.

So in case if there a conflict it will always possible to give a syntax check error.

Also why I find hash approach not enough flexible. Pretend we have now two enums

type Rating5Stars : Integer enum {
  Best  = 5;
  Good  = 4;
  Avg   = 3;
  Poor  = 2;
  Worst = 1;
}

type Rating3Stars : Integer enum {
  Good  = 3;
  Avg   = 2;
  Poor  = 1;
}

//and we have now them in same entity
entity Reviews {
  key ID   : UUID;
  rating_5   : Rating5Stars,
  rating_3   : Rating3Stars
}

// so select like this will look confusing
// it's not clear that those are two different enumns
// if someone changes type of rating_3 to Rating5Stars - 
// it will be considered as correct statemennt by a compiler but will pick up wrong value with same name
view bestReviews as select * from Reviews where rating_5 = #Good and rating_3 = #Good

//that's why I suggest to go with qualified name with enum included
// in case if column type is changed - we should get an error that enum type is not matching ( one more benefit )
view bestReviews as select * from Reviews where rating_5 = Rating5Stars#Good and rating_3 = Rating3Stars#Good

//but again.. isn't it simpler just to use like this ?
view bestReviews as select * from Reviews where rating_5 = Rating5Stars.Good and rating_3 = Rating3Stars.Good

[alexandre_gueriot]

Hi Petr,

You might find what you’re looking for in this blog post.

-Alex

[pepl]

Hi Alex. Thanks for you reply. Well - for sure in JS we have unlimited capabilities.

However this post was about pure CDS modelling part. It's quite simple to declare enums of course. However is not possible to use them in the model as join or filter conditions. That's make usage of enums very limited.

So currently even having enums - we still have to use literals there. I hope CAP team will come with some solution - and here is just the proposal 😃