. Чистые коды хэшей больше не постоянны?

Question

У меня есть API, где различные типы имеют пользовательские хэш-коды. Эти хэш-коды основаны на получении хеша строкового представления рассматриваемого объекта. Используются различные методы соления, так что, насколько это возможно, коды Хэша не сталкиваются и что объекты разных типов с эквивалентными строковыми представлениями имеют разные коды хэша.

Очевидно, что поскольку хэш-коды основаны на строках, существуют некоторые столкновения (бесконечные строки и ограниченный диапазон 32-битных целых чисел). Я использую хеши на основе строковых представлений, так как мне нужно, чтобы хэши сохранялись в течение сеансов и, в частности, для использования в хранилище баз данных объектов.

Внезапно сегодня мой код начал генерировать разные хэш-коды для объектов, которые разрушают всевозможные вещи. Он работал ранее сегодня, и я не использовал код какого-либо кода, связанного с генерированием кода хэш-кода.

Я знаю, что документация .Net позволяет реализовать хэш-коды между версиями каркаса .Net для изменения (и между 32 и 64-разрядными версиями), но я не изменил версию фреймворка и не было никакой инфраструктуры Обновления в последнее время, насколько я помню

Любые идеи, потому что это кажется действительно странным?

Редактировать

Хэш-коды генерируются, как следует:

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

Answer 1

Что StampedeXV предлагает в своем комментарии, так как Object.ToString() вернет полное имя по умолчанию, если ToString() не является избыточным.

1. Изменение пространства имен (или имени класса) изменит это значение, если ToString() не переопределяется.
2. Очевидно, что переопределение ToString() изменит его.
3. Проверьте, как и где находится _nodeType.
4. PlainLiteralHashCodeSalt остается мистерией (я полагаю, это постоянная строка).
5. Никто не гарантирует, что String.HashCode() не изменится, поэтому вы можете хотя бы использовать Reflector, чтобы получить источник методов и включить его в свою библиотеку. Это не что-то, что я обычно рекомендую, но вы не хотите зависеть от этого в будущем.

Излишне говорить, что вы должны отслеживать все 3 значения (_nodeType, this.ToString() и сольную строку), чтобы проверить, что они не изменились. Если вы можете вернуться к более старой версии, которая работает, вы на полпути.

Кроме того, сохранение хеш-кода не рекомендуется. Если это , связанное с производительностью, обратите внимание, что ответственность за индексацию и хеширование лежит на вашей базе данных. И поскольку вы не можете гарантировать его уникальность, это также не GUID. Так в чем же смысл?

Но поскольку он уже находится в базе данных, ваша главная проблема заключается в том, как вернуть реализацию HashCode.

Answer 2

Вы говорите, что вы используете этот хэш-код для персистенции. Это плохая идея с вашей текущей реализацией, потому что вы используете функцию ToString() для генерации хэш-кода. Результат этой функции не связан с персистентностью, и, возможно, разработчику необходимо изменить его для дизайна графического интерфейса или по каким-либо причинам и забыть, что он также используется для настойчивости.
В вашем случае я бы посмотрел на результат метода ToString(), возможно, он изменился. Это может произойти путем изменения культуры или перемещения объекта в другое пространство имен - просто посмотрите, может быть, вы найдете причину.