How do you access data model when you have different project structure/repos? Synonyms do get created, however data models with cds.persistence.exists annotations are still unreachable inside any other .cds file.
You need to reference those files by relative path (if in the same project). Or you can publish and reference reusable cds models via git or npm. The same way you access the SAP provide reuse cds types.
The mta.yaml isn't used at test/run within the Business Application Studio. It's only used during a "real" deployment. Therefore we duplicate the configuration int he default-env.json for "local" testing in the Business Application Studio without having to actually deploy anything to Cloud Foundry. [Thomas Jung]
You would have to treat that like a regular schema and use a User Provided Service to connect to a container in another space. You can not bind directly to a service instance in another space. [Thomas Jung]
What kind of problem are you having? It might be easier to ask your question via the GitHub issues: github.com/SAP-samples/hana-developer-cli-tool-example/issues [Thomas Jung]
Hi Thomas , could you please explain why `entity ![abc]` is used in some cds instead of `entity abc` cap.cloud.sap/docs/cds/cdl talks about delimited identifiers which are used when spaces/special characters/keywords are used as identifiers, any particular reason it is used in user_db schema.cds as I dont see any space or special characters or keywords being used , please clarify . Thanks in advance.
That is the delimited identifier just like you described. The reason it's used here - it never hurts to use it even if there aren't any special characters. But I also used the hana-cli to convert these entities from hdbcds to cds and because it's an automated conversion tool it always uses delimited identifiers just to be safe. [Thomas Jung]
How do you access data model when you have different project structure/repos? Synonyms do get created, however data models with cds.persistence.exists annotations are still unreachable inside any other .cds file.
You need to reference those files by relative path (if in the same project). Or you can publish and reference reusable cds models via git or npm. The same way you access the SAP provide reuse cds types.
Why have you maintained the TARGET_CONTAINER and SERVICE_REPLACEMENTS logic in default-env.json? Shouldn't that logic be added to mta.yaml?
The mta.yaml isn't used at test/run within the Business Application Studio. It's only used during a "real" deployment. Therefore we duplicate the configuration int he default-env.json for "local" testing in the Business Application Studio without having to actually deploy anything to Cloud Foundry. [Thomas Jung]
@@sapdevs Thank you Thomas.
Is it possible to access a HDI container in a different CF space? I tried it, but when deploying I got an error 'the synonym target dos not exist'.
You would have to treat that like a regular schema and use a User Provided Service to connect to a container in another space. You can not bind directly to a service instance in another space. [Thomas Jung]
having a problem using hana-cli tool on a mac, is there an updated tutorial how to configure it?
What kind of problem are you having? It might be easier to ask your question via the GitHub issues: github.com/SAP-samples/hana-developer-cli-tool-example/issues [Thomas Jung]
Hi Thomas , could you please explain why `entity ![abc]` is used in some cds instead of `entity abc`
cap.cloud.sap/docs/cds/cdl
talks about delimited identifiers which are used when spaces/special characters/keywords are used as identifiers, any particular reason it is used in user_db schema.cds as I dont see any space or special characters or keywords being used , please clarify .
Thanks in advance.
That is the delimited identifier just like you described. The reason it's used here - it never hurts to use it even if there aren't any special characters. But I also used the hana-cli to convert these entities from hdbcds to cds and because it's an automated conversion tool it always uses delimited identifiers just to be safe. [Thomas Jung]