Hi Carsten
As a general point, I think you should be very wary of using as an ID a field whose value can be changed.
For instance, consider the predicament of a consumer who has the ID and wants to use it to retrieve your usage entity. If you change the ID "behind the back of the consumer" the consumer won't know how to recover.
I would strongly recommend using an invariant value as an ID, this could be a GUID (if you have enough storage), or a database sequence, or some other way of generating random but non-repeatable values.
I don't know enough about the usage domain to assess if this is worth an exception, you need to examine your use cases and data flows very carefully.
Hope it helps
------------------------------
Jonathan Goldberg
Amdocs Management Limited
Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.
------------------------------
Original Message:
Sent: Nov 10, 2020 03:58
From: Carsten Zimmermann
Subject: Is the ID of a Usage Entity modifyable?
Dear collleagues,
I am wondering whether the id firld of a Usage entity can be modified when it (the usage) represents a recurring fee. I was considering to map our Source Transaction ID to the id field of the usage entity, as it identifies the usage regardless of whether it is created on a recurring basis or based on actual CDRs. During rerating, however, the Source Transaction ID will be issued again, since old RatedProductusagees will be put aside and replaced by new ones. Hence a new primary key makes sense.
Is that allowed?
With kind regards
------------------------------
Carsten Zimmermann
Deutsche Telekom AG
------------------------------