In the first part of my blog post, I've shown how you can get familiar with cds.ql and how the syntax works for you. If you are not very familiar with cds.ql so far, I'd recommend to read the documentation (https://cap.cloud.sap/docs/node.js/cds-ql) ...
CAP and its documentation capire are continuously growing (https://cap.cloud.sap/docs/node.js/cds-ql). While there are many code samples, it might be overwhelming to understand the object-relational querying syntax of CAP. The aforementioned document...
CAP (Cloud Application Programming) has been the de-facto standard for cloud-native development on BTP. Over the years, it has grown in stability, functionality and usability. With just a few annotations, an entire Fiori Elements app is generated fro...
This blog post is the next part of my series of a random collection of useful code fragments. You can find part 1 here, where I have focussed especially on Fiori Elements and SAPUI5.
The CAP documentation has added some detailed explanation on how f...
CAP applications in either NodeJS or Java are a powerful tool for rapid development in the cloud. With simplified syntax, it is reasonably simple to create a beautiful and powerful application.
Creating an application based on HANA Cloud simplifies ...
Thank you for the clarification David
So SELECT. and UPDATE. all return Promises of the db execution, right? Is const tx = cds.tx(req), recommended to be used or what's the new best-practice?
Best regards,
Leo
This would be new to be, that tx.run is not needed anymore. All your previous examples still do return queries and not results of the db transaction (also since db execution is async). Therefore, you could use also late materialisation to create subq...