on ‎2021 Aug 10 9:12 AM
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
Request clarification before answering.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
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 hereFacade 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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
| User | Count |
|---|---|
| 7 | |
| 6 | |
| 6 | |
| 5 | |
| 4 | |
| 3 | |
| 3 | |
| 3 | |
| 2 | |
| 2 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.