cancel
Showing results for 
Search instead for 
Did you mean: 

CAP - Auto-incremental IDs / numbering, use of hdbsequence/hdbtrigger/hdbsynonym

ssimsekler
Active Contributor

Hello

It seems CAP model does not yet offer a streamlined numbering capability like ABAP (number objects) or HDI (hdbsequence & hdbtrigger).

It seems it is possible to use HDI. However, the limited examples I found seem to include schemas/namespaces whereas schema management is hidden in CAP and I am not sure how to refer the tables that CAP manages. So, I am not sure how HDI and CAP can be implemented together. For example, given the following entity definition:

namespace example.cloud.application;

entity BPartners : managed, cuid {
  seqID : Integer;
  name: String;
}

1. What should the .hdbsequence file content look like if it needs to (e.g. for reset_by) refer to the table that is linked to the above entity definition?

2. How do we retrieve nextval/currentval from the hdbsequence in Node.js?

3. Because the number is ideally to be increased at the time of DB save, may the event handlers at service level be too early to increase the counter and assign the ID, e.g. on .before ('CREATE'...)? If yes and if .hdbtrigger & .hdbsynonym need to be used, how should their contents look like?

Kind Regards

lbreddemann
Active Contributor
0 Kudos

The recommendation in CAP is to use GUIDs instead, as these don't require any synchronization. E.g. you never will have to "clear up" used IDs with GUIDs when moving code and (test)-data between systems.

This also steers away from the misunderstanding that surrogate-IDs (like the automatically created seqID) have any meaning beyond their uniqueness.

There must not be an implied order or "uninterrupted streak" of values in a surrogate-ID. If it is, then this ID has application meaning and needs to be handled differently.

ssimsekler
Active Contributor

Hi lars.breddemann

Thanks for your comment. We already use GUIDs and from the technical aspect I love them. But, as you know business would need mnemonic/human readable IDs. For example, when customers call, they cannot ask their account GUID; rather, they will ask their account ID.

I believe this is a significant requirement that needs to be supported. So, do you have any suggestions if we have to do this?

View Entire Topic
ssimsekler
Active Contributor
0 Kudos

I'd accept Jhodel's answer, but it may be misleading as actually the actual solution is in the comments and you need to "Show all" to see the full discussion and the solution. So, under Jhodel's answer, click "Show all" and check out the comments to see the solution perspective.

Also, we had a nice discussion around this under Jhodel's blog here (which actually provides a structured content for a solution) with Lars and Jhodel, where I was insisting on human readable IDs and provided justification. You can go and have a look there, too.

Thanks, Jhodel.