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
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
48 changes: 48 additions & 0 deletions guides/databases.md
Original file line number Diff line number Diff line change
Expand Up @@ -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:


```xml
<execution>
<id>cds.build</id>
<goals>
<goal>cds</goal>
</goals>
<configuration>
<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?

</commands>
</configuration>
</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`.

Once you have 2 non-HANA local databases you need to have 2 distinct database configurations in your Spring Boot configuration (in most cases application.yaml).

```yaml
spring:
config:
activate:
on-profile: default,h2
sql:
init:
schema-locations: classpath:schema-h2.sql
---
spring:
config:
activate:
on-profile: postgresql
sql:
init:
schema-locations: classpath:schema-postgresql.sql
datasource:
url: "jdbc:postgresql://localhost:5432/my_schema"
driver-class-name: org.postgresql.Driver
hikari:
maximum-pool-size: 1
max-lifetime: 0
```
In case you use 2 different databases you also need to make sure that you have the JDBC drivers configured (on the classpath).
</div>

CAP samples demonstrate this in [cap/samples/fiori](https://github.com/SAP-samples/cloud-cap-samples/commit/65c8c82f745e0097fab6ca8164a2ede8400da803). <br>
There's also a [code tour](https://github.com/SAP-samples/cloud-cap-samples#code-tours) available for that.