Clever Geek Handbook

.Net Hash Codes not saving anymore?

I have an API where different types have their own hash codes. These hash codes are based on obtaining a hash of the string representation of the object in question. Different salting methods are used so that, as far as possible, Hash codes do not collide and that objects of different types with equivalent string representations have different hash codes.

Obviously, since hash codes are string based, there are some collisions (infinite strings versus limited range of 32 bit integers). I use hashes based on string representations, as I need the hashes to persist across sessions and in particular for use in the database data store.

All of a sudden my code today started generating different hash codes for objects that break all sorts of things. It worked already today and I have n't touched on any code related to hash code generation.

I know the .Net documentation allows hashes to be implemented between .Net framework versions to change (and between 32 and 64-bit versions), but I haven't changed the framework version and there haven't been any framework updates lately as far as I remember

Any ideas because this seems really weird?

Edit

Hash codes are generated as follows:

//Compute Hash Code
this._hashcode = 
   (this._nodetype + this.ToString() + PlainLiteralHashCodeSalt).GetHashCode();
+2


source to share


2 answers


What StampedeXV suggests in its comment is that it Object.ToString()

will return the default fully qualified name if ToString()

not overridden.

  • Changing the namespace (or class name) will change this value unless ToString()

    overridden.
  • Obviously overriding ToString()

    would change it.
  • Check how and where changes _nodeType

    .
  • PlainLiteralHashCodeSalt

    remains mistery (I assume it is a constant string).
  • Nobody guarantees that String.HashCode()

    it won't change, so you can at least use Reflector to get the source of the methods and include it in your library. This is not what I usually recommend, but you don't want to depend on it in the future.

Needless to say, you must keep track of all 3 values ​​(_nodeType, this.ToString () and the solo string) to check that they haven't changed. If you can revert to an older version that works, you're halfway there.



Also, storing the hash code is not recommended. If this is performance related , please note that the responsibility for indexing and hashing lies with your database. And since you cannot guarantee that it is unique, it is not a GUID either. So what then?

But since it is already in the database, your main problem is how to return the HashCode implementation.

+3


source


You say you are using this hash for persistence. This is a bad idea with your current implementation, because you are using a function ToString()

to generate a hash code. The result of this feature is not about persistence and maybe the developer needs to change it for GUI design or for some reason and forget that it is also used for persistence.
In your case, I would look at the result of the method ToString()

, it may have changed. This can happen by changing the culture or by moving the object to a different namespace - just take a look, you may have found the cause.



+1


source






More articles:


All Articles