5 ms·

(Disclaimer: I work here) The SAP Cloud Application Programming Model (CAP) let's you derive your DB schema and UI from one semantic data model. The runtime fr

(Disclaimer: I work here) The SAP Cloud Application Programming Model (CAP) let's you derive your DB schema and UI from one semantic data model. The runtime framework interprets this and provides (deep) CRUD functionality out of the box. Business logic can then be inserted using different request handlers. Therefore you have (depending on additional business logic) usually only one place to define your model. https://cap.cloud.sap/docs/ https://cap.cloud.sap/docs/

mustardo 5y ago
Wow such spam, and SAP wow... What trash
jaywalk 5y ago
You're clearly not a spammer so I want to go easy on you, but nobody on HN is looking for a SAP sales pitch. I can promise you that.
- davidkunz 5y ago
  I'm sorry, it wasn't meant to be a sales pitch (it's free to use anyway), I just wanted to show another way to deal with the "you change your database model, now you have to change many other places too" problem.
  - cromulent 5y ago
    I didn't think you were shilling, but I was a little disappointed not to get a deep link to the docs for that specific capability :)
    - davidkunz 5y ago
      It's all built around that feature. You define your model using the language CDS (core data services), after compilation, you'll get a JSON representing the model (used by the generic runtime, either Node.js or Java), table/view SQL statements for the databases SQLite/HANA and OData metadata used by generic UIs. That means you semantically define your model and get all the artifacts needed to run the application. With generic support for most "enterprise qualities" like authorization, localization, draft support, extensibility etc. https://cap.cloud.sap/docs/get-started/in-a-nutshell https://cap.cloud.sap/docs/get-started/in-a-nutshell gives a first glimpse. But again, I don't want to advertise. Like everything else, this approach has pros and cons, just wanted to give some insights how we dealt with that problem.
mleonhard 5y ago
Does it provide tooling for migrating from one version of the data model to another? How does it handle the issues described in the article?
- davidkunz 5y ago
  There is some migration tooling (HANA), but it won't be able to solve all issues (no framework can), as it strongly depends on how your migration looks like. However, it's purely declarative (for the generic CRUD operations), which helps you "experimenting" with different approaches more easily. It supports projections and allows CRUD operations on them (if the projections are not too complicated). For some migrations this is sufficient, but of course not if your additional business logic depends on it. The real power is more regarding the server/UI layer as you will be able to change the server code without needing to change the UI (except if you have custom UI code), as the UI is dynamically constructed based on the model metadata coming from the server. In your migration, this is not a big problem as you can pin newer versions of your UI to newer versions of your server, but here you just don't have to, which is neat.

mustardo 5y ago

Wow such spam, and SAP wow... What trash

jaywalk 5y ago

You're clearly not a spammer so I want to go easy on you, but nobody on HN is looking for a SAP sales pitch. I can promise you that.

davidkunz 5y ago
I'm sorry, it wasn't meant to be a sales pitch (it's free to use anyway), I just wanted to show another way to deal with the "you change your database model, now you have to change many other places too" problem.
- cromulent 5y ago
  I didn't think you were shilling, but I was a little disappointed not to get a deep link to the docs for that specific capability :)
  - davidkunz 5y ago
    It's all built around that feature. You define your model using the language CDS (core data services), after compilation, you'll get a JSON representing the model (used by the generic runtime, either Node.js or Java), table/view SQL statements for the databases SQLite/HANA and OData metadata used by generic UIs. That means you semantically define your model and get all the artifacts needed to run the application. With generic support for most "enterprise qualities" like authorization, localization, draft support, extensibility etc. https://cap.cloud.sap/docs/get-started/in-a-nutshell https://cap.cloud.sap/docs/get-started/in-a-nutshell gives a first glimpse. But again, I don't want to advertise. Like everything else, this approach has pros and cons, just wanted to give some insights how we dealt with that problem.

mleonhard 5y ago

Does it provide tooling for migrating from one version of the data model to another? How does it handle the issues described in the article?

davidkunz 5y ago
There is some migration tooling (HANA), but it won't be able to solve all issues (no framework can), as it strongly depends on how your migration looks like. However, it's purely declarative (for the generic CRUD operations), which helps you "experimenting" with different approaches more easily. It supports projections and allows CRUD operations on them (if the projections are not too complicated). For some migrations this is sufficient, but of course not if your additional business logic depends on it. The real power is more regarding the server/UI layer as you will be able to change the server code without needing to change the UI (except if you have custom UI code), as the UI is dynamically constructed based on the model metadata coming from the server. In your migration, this is not a big problem as you can pin newer versions of your UI to newer versions of your server, but here you just don't have to, which is neat.