We are looking at a new portal application that will have large amounts of data with transaction ID's that will need to be user friendly.   Once you get into a DB IDs over 9 or 10 digits it starts to get rather messy. 

I was thinking about taking the DB id and doing a CRC32 hash on it so the displayed ID is always 8 digits in length.  I don't think OS provides this out of the box so before I start down that path I wanted to see if anyone else has run into this and if there is a more elegant solution than the one I'm considering.

Hi, 

Isn't the use case for CRC32 hashing to detect changes (or for that matter tampering of data)?

The only, quick search in the OutSystems Forge showed me the following:

https://www.outsystems.com/forge/component-overview/6837/crc

I am not convinced btw that an 8 length CRC32 code like "f1a5d764" is so much easier to read or than the number 871239023037 from which it is derived. Both have no meaning.

Regards,

Daniel

Hi Josh.

Your idea is good.

I wouldn't go with hash when I can keep it sequential.

An easy approach would be to change to hexadecimal. 6 digits can save 16M ids. You can still use the long integer internally, and to convert decimal to hexa and vice-versa when working with user inputs. Check this component.

You can also make a function to work in base 26, use the alphabet, and have 300M in the same 6 chars.


Which component Nuno?

Daniël Kuhlmann wrote:

Hi, 

Isn't the use case for CRC32 hashing to detect changes (or for that matter tampering of data)?

The only, quick search in the OutSystems Forge showed me the following:

https://www.outsystems.com/forge/component-overview/6837/crc

I am not convinced btw that an 8 length CRC32 code like "f1a5d764" is so much easier to read or than the number 871239023037 from which it is derived. Both have no meaning.

Regards,

Daniel


Yes that is the traditional use case.   Frankly I'm just looking for a way to shrink a very large number into one that is more manageable.  I agree that a length of 8 is still large but it would never increase over that length so user experience is consistent.

Nuno Reis wrote:

Daniël Kuhlmann wrote:

Which component Nuno?

Sorry, missed it.

https://www.outsystems.com/forge/component-overview/5548/hex-conversion

Thanks, I will check this out.   I think the base 26 is would be the best option as my testing shows that when using a 10 digit int the Hex result is 8 digits in length, but after that it is essentially length -2 for the HEX.


The CRC-32 Hash does seem to be better result length for incredibly large numbers.  

Nuno, can you elaborate on how I might go about making this work in base-26  (resulting in 300M possible IDs via a 6 character HEX)

I did the math and we will be generating around 38-48M records per year so a standard HEX encode will not be sufficient.   I will need to be able to encode all of our record IDs and ensure that the resulting HEX is never duplicated  (which is why I've determined a hash is not a good option).   This way when someone calls in to check the status of their activity we never had to worry about it being linked to the multiple records.   

Solution

I made this action to convert Id into Base26.

0,1,2,3,4... becomes A,B,C,D...

1000 = BMM

300000000 = ZGMSZO




Id is auto-generated. You determine the "Hash" and save it to the table. Internally, you can use Id. Outsiders must provide Hash and you can search by it. It is unique and can be indexed.


I could attach the module, but you must do it to feel it.


Solution

Thank you, I will take some time to digest this but it looks promising.   Truth be told, we are transitioning our portal from Siebel and are trying to mimic the ROW-ID that is created for records there.   When I look up information about how that is calculate it simply says it's a base 36 sequence generated using a proprietary algorithm but frankly... I think I could be close enough by using a single digit prefix and then encoding our DB IDs using Base-36.

http://onlysiebel.blogspot.com/2009/10/what-is-row-id.html

You can change my code to base 36, or anything. Simply make that assign base26 into something more complex. I avoid mixing zeros and O's,  ones.and I's when users may input them (bad experiences with unreadable YouTube video ids).

Thanks, I'm thinking that I might actually create an extension that I can pass the Int into and get back the Base-36 string.  Still weighing options.  I appreciate your feedback!