Increased length of surrogate keys

Jump to solution
Community Member

Hello. It appears that our surrogate keys recently increased in length by the addition of '111' at the start of all of them. For example, a course_dim id that previously had been 60000000123456 is now 11160000000123456. This led to issues with our loading the data into a local Oracle database for reporting.

Should we anticipate future changes of this sort? What is the best way to be informed about them before they happen.

Thank you.

1 Solution


Happy to chime in here. So what actually happened is unique to your University. The change that occurred here was a result of something called a shard split. A Shard Split is a maintenance event some of our older customers have to go through due to a change in our architecture we had a few years ago.

Generally we warn users of the affect this has on Canvas Data, but it turns there was a slip in this process, something which we've since corrected, and enforced following the template. So there's little to no means of miss communication.

Essentially what happens in a shard split is their internal "Shard ID" changes. Since the "id"'s are based off of the Shard ID, these IDs of objects also changed (increasing in length). This is a stable change, and from now on you should always have IDs the same length.

One part I'm confused about though is why you're using IEEE-754 for IDs? IEEE-754 deals with floating point numbers, even though an ID will never be a floating point number. Was there documentation somewhere we can update that led you to this conclusion?, Maybe somewhere we can clarify that a bit better. Anyway you should be able to use a BIGINT (or other 64 bit integer), or a String to represent these IDs.

If you have any further questions please don't hesitate to ask.



View solution in original post