Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Native functions w/ diff DBs for CAP Java #1452

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

rjayasinghe
Copy link
Contributor

In order to use database dependent CDS models with CAP Java applications you need to consider some additional steps. Those are added to the database guide in this commit.

In order to use database dependent CDS models with CAP Java applications you
need to consider some additional steps. Those are added to the database
guide in this commit.
@@ -968,6 +968,54 @@ In case of conflicts, follow these steps to provide different models for differe
}
}}}
```
<div markdown="1" class="impl java">

3. For CAP Java setups you might need to reflect the different profiles in your CDS Maven plugin configuration. This might not be needed for all setups. For mixed local DB (sqlite, H2, or PostgreSQL) and hybrid HANA setup nothing special needs to be done since the local build defaults to the `development` profile. But for other setups like e.g. local PostgreSQL and SQLite you'll need two (profiled) `cds deploy` commands:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I understand it correctly, this is about using two different DBs locally. If it's only one DB locally and one DB (HANA, Postgres) for production, then you can stay with the defaults, right?

Suggested change
3. For CAP Java setups you might need to reflect the different profiles in your CDS Maven plugin configuration. This might not be needed for all setups. For mixed local DB (sqlite, H2, or PostgreSQL) and hybrid HANA setup nothing special needs to be done since the local build defaults to the `development` profile. But for other setups like e.g. local PostgreSQL and SQLite you'll need two (profiled) `cds deploy` commands:
3. For CAP Java setups you might need to reflect the different profiles in your CDS Maven plugin configuration. This might not be needed for all setups, like using a standard local database (sqlite, H2, or PostgreSQL) and a production SAP HANA setup. In that case the local build defaults to the `development` profile. But for other setups, like using a local PostgreSQL and a local SQLite you'll need two (profiled) `cds deploy` commands:

<commands>
<command>build --for java</command>
<command>deploy --profile development --dry --out "${project.basedir}/src/main/resources/schema-h2.sql"</command>
<command>deploy --profile production --dry --out "${project.basedir}/src/main/resources/schema-postresql.sql"</command>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If my assumption (two local DBs) is correct, why is the production profile needed here?

</execution>
```

4. For the Spring Boot side it's similar. If you have a local development DB and a hybrid profile with a remote HANA DB you only need to run in default (or any other) profile and you get the local DB and it's SQL schema that was written to your `src/main/resources`. For the HANA part the build and deploy part is done seperately and the application just needs to be started with a local `default-env.json` file and `cloud` profile or via `cds bind`.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess we should not promote the default-env.json case anymore when we have the more secure cds bind. But it's not started using cds bind, right? We need to rephrase that.
I removed some parts as I thought that is too detailed and probably not needed. But of course you can change my mind ;)

Suggested change
4. For the Spring Boot side it's similar. If you have a local development DB and a hybrid profile with a remote HANA DB you only need to run in default (or any other) profile and you get the local DB and it's SQL schema that was written to your `src/main/resources`. For the HANA part the build and deploy part is done seperately and the application just needs to be started with a local `default-env.json` file and `cloud` profile or via `cds bind`.
4. For the Spring Boot side it's similar. If you have a local development database and a hybrid profile with a remote SAP HANA database, you only need to run in default (or any other) profile. For the SAP HANA part, the build and deploy part is done separately and the application just needs to be started using `cds bind`.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants