Increased length of surrogate keys

Jump to solution
s_moles
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.

0 Likes
1 Solution
ccoan
Instructure Alumni
Instructure Alumni

Hello,

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.

Thanks,

Eric

View solution in original post