I am feeding ACC nms:broadLogEventHisto data to a legacy system which cannot accept primary keys that are larger than 32 bit integers, but needs a unique value to represent the records. The reason for this can be ignored for this use case.
It turns out, all broadLog tables, with the exception of those related to message center, have a 32 bit integer PK incrementing via the NmsBroadLogId sequence:
I would like to retain the @id field in the broadLogEventHisto schema (without changing the internal name), since the OOTB message center workflow process references and updates data via the name of that attribute, while also adding an additional unique attribute (name = "broadLogEventHistoId32bit") that will run on the same sequence as what is used for the id for tables built off nms:broadLog and auto-increment -- i.e. @id in nms:broadLogRcp. However, extending this table and declaring: autopk="true" pkSequence="NmsBroadLogId", automatically adds a key field with the name @id, which is already taken by the PK in broadLogEventHisto that i wanted to retain. Additionally, i have explored using a counter, but i am unsure how to make the value restart at 0 once all 32bit integer values are consumed. Essentally, i want this new attribute to operate in the same exact manner as @id in nms:broadLogRcp
So my questions are:
1) Where is it decided what autopk="true" names the auto-created PK value?
2) How can i add a value that mimics @id in nms:broadLogRcp within nms:broadLogEventHisto, while retaining the current int64 bit field @id.