cancel
Showing results for 
Search instead for 
Did you mean: 
Read only

CAP Table and Column Names are all in Uppercase after Build

Domae
Participant
0 Likes
3,034

Hey guys,

I am new to CAP and I noticed that after each build of my project, all tablenames and columnnames are transformed to uppercase. Is there a way to omit that? I want my columns and tables to stay in mixedcase.

Before Build in the *.cds file:

entity Validation_Customizing {
    key ruleId         : String  @(title : '{i18n>ruleId}', assert.notNull: true);
        ruleName       : String  @(title : '{i18n>ruleName}');
        toBeValidated  : Boolean @(title : '{i18n>toBeValidated}');
        procedureAffix : String  @(UI.Hidden : true);
}

After Build in the *.hdbcds file:

entity VALIDATION_CUSTOMIZING {
  key RULEID : String(5000);
  RULENAME : String(5000);
  TOBEVALIDATED : Boolean;
  PROCEDUREAFFIX : String(5000);
};

I already tried to look for some build parameters but without any success.

Best Regards

Dominik

Accepted Solutions (1)

Accepted Solutions (1)

hjb
Product and Topic Expert
Product and Topic Expert
0 Likes

Hello,

my first question is: why would you want mixed case identifiers in the database?

At least our conviction is that quoted identifiers cause more pain than gain in the long run.

We consider an activation via SQL CREATE TABLE/VIEW statements as the default. Unquoted identifiers in CREATE TABLE/VIEW/... are converted to the native database representation, in case of HANA all uppercase.

To allow a compatible transition from HANA CDS to native SQL, all identifiers are converted to uppercase in the HANA CDS file because HANA CDS will quote identifiers in the final CREATE statements.

Converting quoted identifiers to plain identifiers is a major effort, especially if you have to convert live models without interruption. And with the availability of smart quoting in CDS compiler version 2 also reserved SQL keywords can be used as regular identifiers (eliminating the last need for explicit quoting).

With regards, Hans-Joachim

Domae
Participant
0 Likes

Hi Hans-Joachim,

thanks for the clarification on this. Well to answer your question, I am currently working with the FSDM data model from SAP. And in this data model, all table- and columnnames in tables/tabletypes are in mixed case. So when I have a procedure with a fsdm tabletype as input parameter and I want to pass a table which I created myself in CAP CDS, then I have to pass an uppercase table to this procedure which expects a mixed case table type. That's why I wanted to compile my cap tables in mixed case and not in upper case.

But we changed our logic now to upper case. So I was just wondering if the developer would have the choice to switch between upper and mixed case.

Nevertheless I agree with you, upper case should be the default.

Best Regards

Dominik

SrinivasanG
Advisor
Advisor
0 Likes
Hi Hans,
SrinivasanG
Advisor
Advisor
0 Likes
Hi Hans- Joachim, I was trying to create a Function import which returns the array of the entity types. Here we had the same issue of upper case in the HANA DB. We had to manually map the values to Camel case and send it to response as direct mapping didn't work. Is there any way to simplify this so that we dont have to map each and every field of the entity to camel case. Thanks & Regards, Srinivasan

Answers (1)

Answers (1)

hjb
Product and Topic Expert
Product and Topic Expert
0 Likes

Hi Dominik,

thanks for providing more details, I get your point. Well, at least you should try to keep mixed case objects as low as possible. One option could be to create a mixed case table outside of the CDL domain and introduce it into the CAP layer via a mapping view and a facade entity.

The most convenient way would be to reuse the FSDM table type as blue print for your table, but unfortunately 'LIKE' is not allowed by hdbtable 😞

CREATE TABLE <name> LIKE <table_type>

Instead you have to create the table with explicit column and key definitions as duplicate of the FSDM table type). But by just creating the table once manually with 'like <tt>' and reading out the CREATE statement this should be an easy task.

A very rough and sketchy Example (from my scratch SQL CLI):

create  type tt as table ("id" integer primary key, "daTa" nvarchar(100));
-- the table containing matching column names (hdbtable artifact)
create table e like tt;
-- mapping view to convert explicit mixed case into plain format (hdbview artifact)
create view mapper as select "id" as id, "daTa" as data from e;
-- proof that this 1:1 view is updatable
insert into mapper values (1, '100');
select * from e;
-- CDS facade entity is not shown here

Facade entitites including element mapping are described in great detail here https://cap.cloud.sap/docs/advanced/hana

This way you would maintain plain artifact/element names inside the CDS domain and get a low level mapping into the table that you want to pass into the procedure. Would that work for you?


Of course these tables/views must be maintained by you (but I guess these static APIs are no subject for frequent changes). The benefit is that you keep these adaptation particularities out of your grand naming scheme.

HTH, Hans-Joachim

Domae
Participant
0 Likes

Hey Joachim,

sorry for my late response and thanks for your great support. This would work for us I think. But unfortunately we changed our logic fully to uppercase, so that we are working with best practises again!

Best regards

Dominik