The biggest problem we currently have when generating the hash is allowing for exclusions: fields that should not be accounted for when a unique hash has to be generated.
This is complicated for two reasons:
we have a property that HAS to be excluded every time when computing the hash: the BHoM_Guid.
(The reason is obvious: we want the hash to be representative of the instance of the object, a combination of all its properties; the BHoM_Guid is randomly re-established every time, say, the Grasshopper definition is reopened, upon object instantiation).
The BHoM_Guid is ubiquitous, at all levels: every object has it, and a single BHoM Object may contain other sub-objects that have other BHoM_Guids.
In general, the BHoM_Guid simply constitutes the worst-case for the hash generation mechanism.
Anyway, the approach is:
generate a byte serialisation of the object, making sure the serialisation excludes the unwanted properties
feed the byte array to a hash algorithm. I am using SHA256 here.
For the byte serialisation originally was to use Mongo's byte serialisation that allowed to exclude certain properties. This was actually suggested by @adecler a while ago. However, that did not work, as Mongo's exception where limited to the first level properties only. This means that BHoM_Guid of sub-objects (e.g. Nodes of a Bar) were not excluded, and the hash was incorrectly computed.
For this reason, given the impeding need of the hash in the Diffing Engine, I had to revert to another working solution. I am currently serialising the object into a string, then I discover and remove the unwanted properties. Obviously, this is slow, but it works reliably.
Another reason to tackle this: in order to solve the property search a bit more efficiently I used some methods fromNewtonsoft.Json, which is a reference we want to remove from the BHoM_Engine. Therefore, solving this issue would solve also https://github.com/BHoM/BHoM_Engine/issues/1885.
I spent quite some time researching for better alternatives, but I feel like I hit a wall, and I really would appreciate the help of @adecler to see what we can do with Mongo or other solutions.
Description:
The biggest problem we currently have when generating the hash is allowing for exclusions: fields that should not be accounted for when a unique hash has to be generated.
This is complicated for two reasons:
we have a property that HAS to be excluded every time when computing the hash: the
BHoM_Guid
.(The reason is obvious: we want the hash to be representative of the instance of the object, a combination of all its properties; the BHoM_Guid is randomly re-established every time, say, the Grasshopper definition is reopened, upon object instantiation).
The
BHoM_Guid
is ubiquitous, at all levels: every object has it, and a single BHoM Object may contain other sub-objects that have otherBHoM_Guid
s.In general, the BHoM_Guid simply constitutes the worst-case for the hash generation mechanism.
Anyway, the approach is:
For the byte serialisation originally was to use Mongo's byte serialisation that allowed to exclude certain properties. This was actually suggested by @adecler a while ago. However, that did not work, as Mongo's exception where limited to the first level properties only. This means that
BHoM_Guid
of sub-objects (e.g. Nodes of a Bar) were not excluded, and the hash was incorrectly computed.For this reason, given the impeding need of the hash in the Diffing Engine, I had to revert to another working solution. I am currently serialising the object into a string, then I discover and remove the unwanted properties. Obviously, this is slow, but it works reliably.
Another reason to tackle this: in order to solve the property search a bit more efficiently I used some methods from
Newtonsoft.Json
, which is a reference we want to remove from the BHoM_Engine. Therefore, solving this issue would solve also https://github.com/BHoM/BHoM_Engine/issues/1885.I spent quite some time researching for better alternatives, but I feel like I hit a wall, and I really would appreciate the help of @adecler to see what we can do with Mongo or other solutions.