Your achievements

Level 1

0% to

Level 2

Tip /
Sign in

Sign in to Community

to gain points, level up, and earn exciting badges like the new
BedrockMission!

Learn More

View all

Sign in to view all badges

New 32bit PK attribute (that references NmsBroadLogId sequence) on an nms:broadLogEventHisto schema, but does not overwrite the current field @id (int64)

Avatar

Avatar
Boost 1
Level 1
rayfinkle_72
Level 1

Like

1 like

Total Posts

6 posts

Correct Reply

0 solutions
Top badges earned
Boost 1
Validate 1
View profile

Avatar
Boost 1
Level 1
rayfinkle_72
Level 1

Like

1 like

Total Posts

6 posts

Correct Reply

0 solutions
Top badges earned
Boost 1
Validate 1
View profile
rayfinkle_72
Level 1

26-02-2021

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:

rayfinkle_72_0-1614396212916.png

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.

 

 

FYI - @wodnicki 

Accepted Solutions (1)

Accepted Solutions (1)

Avatar

Avatar
Establish
MVP
wodnicki
MVP

Likes

960 likes

Total Posts

1,087 posts

Correct Reply

506 solutions
Top badges earned
Establish
Affirm 500
Contributor
Shape 1
Give Back 100
View profile

Avatar
Establish
MVP
wodnicki
MVP

Likes

960 likes

Total Posts

1,087 posts

Correct Reply

506 solutions
Top badges earned
Establish
Affirm 500
Contributor
Shape 1
Give Back 100
View profile
wodnicki
MVP

26-02-2021

Hi,

 

The nms:broadLogEventHisto/@id col is populated by mcSynch_local workflow, which sets it to:

$int64(vars/@CELL_OFFSET)*$long(vars/@cellId) + @ID

  • vars/@CELL_OFFSET = '72057594037927936' (string since js doesn't go up that high, 2**52)
  • vars/@cellId = xtk:option NmsExecutionInstanceId
  • @ID= nms:broadLogRtEvent/@id

 

If you only have 1 exec instance, set its execution id to 0 in Deployment wizard, it'll get rid of the offset, no further work needed.

 

If you have >1 exec instances, you'll need the offset- it's what keeps the logs from colliding when they're collated on the control instance.

To fix (seems like how it should work ootb?):

  1. Rename the existing @ID col to @idExec or something else
  2. Change the mcSynch_local workflow to write to renamed id col
  3. Make an ordinary autopk col called @ID with its own pkSequence so as not to consume XtkNewId

 

Thanks,

-Jon

Answers (0)