Loss of significance in cast to integer?

[stgnet]

https://github.com/mrjgreen/db-sync/blob/d484fce270af42a86f980afe53cbcbc1cbac6685/src/Hash/HashAbstract.php#L7

It would appear that the cast to integer looses significance of the hash value. For example with an MD5 hash selected:

select md5('#'), cast(md5('#') as unsigned); +----------------------------------+----------------------------+ | md5('#') | cast(md5('#') as unsigned) | +----------------------------------+----------------------------+ | 01abfc750a0c942167651c40d088531d | 1 | +----------------------------------+----------------------------+

The MD5 hash would appear to be truncated starting at the first character that is not 0-9.

[mrjgreen]

Hi, thanks for opening this!

https://github.com/mrjgreen/db-sync/blob/d484fce270af42a86f980afe53cbcbc1cbac6685/src/Hash/HashAbstract.php#L26

You can see here that we convert the hex string to a decimal integer, so the situation you have described never occurs. Its actually more like this:

mysql> SELECT CAST(CONV(SUBSTR(MD5('#'),1,16),16,10) as unsigned);
+-----------------------------------------------------+
| CAST(CONV(SUBSTR(MD5('#'),1,16),16,10) as unsigned) |
+-----------------------------------------------------+
|                                  120467394665419809 |
+-----------------------------------------------------+
1 row in set (0.00 sec)

Are you experiencing some kind of problem that you had thought may be down to this? It would have been good to know what you are seeing when testing dbsync against your database and what you would have expected to see.

Cheers Joe

[stgnet]

I was not testing the code, merely trying to understand it. Although I believe that since an MD5 hash is set to 2 bytes, this particular line of code does not come into play, thus I may have been hasty to find fault with it.