Build 1.1.0 has a new ID generation scheme, as discussed in this forum thread.
The approach that I've taken is simpler then the one described in that thread -- the encoding for the IDs is fully bi-directional, so there is no "mangling".
Older datasets will work just fine with this new version, since it knows how to resolve the old Base64-style IDs.
The new ID generation scheme is documented on the main nhaystack page, in Section 6 at the end. I will repeat it here for convenience:
How IDs are generated
Each haystack rec must have an ID that uniquely identifies the object that the rec models.
By default, nhaystack generates IDs based on the slotPath of components (or the history ID for histories that are not associate with a point). E.g:
In the above example, the "C" prefix stands for the ComponentSpace, and the "H" stands for the HistorySpace.
Note that IDs are bi-directionally encoded -- you can always recreate the slotPath from an ID and vice-versa.
Special characters in the slotPath are handled by replacing the "$" character with a "~" character. The sole exception to this rule is that "$20", which represents a single " " character, is replaced with a dash, "-", to improve the readability of the IDS. E.g:
If there is a site-equip-point hierarchy created in the station, then nhaystack will use that to generate the ID rather than the slotPath. E.g. if the SineWave in the first example was tagged up with an equip and a site, then its generated ID might look something like this:
slot:/Foo/SineWave1 --> S.Carytown.AHU1.SineWave1
In this case, there are actually two IDs that can be used to resolve the rec -- the slotPath version, and the Site-Equip-Point version.
Note that older versions of nhaystack used a Base64 encoding of the slot path, which looks something like this:
Mike Jarmy Tue 17 Sep 2013
Build 1.1.0 has a new ID generation scheme, as discussed in this forum thread.
The approach that I've taken is simpler then the one described in that thread -- the encoding for the IDs is fully bi-directional, so there is no "mangling".
Older datasets will work just fine with this new version, since it knows how to resolve the old Base64-style IDs.
The new ID generation scheme is documented on the main nhaystack page, in Section 6 at the end. I will repeat it here for convenience:
How IDs are generated
Each haystack rec must have an ID that uniquely identifies the object that the rec models.
By default, nhaystack generates IDs based on the slotPath of components (or the history ID for histories that are not associate with a point). E.g:
In the above example, the "C" prefix stands for the ComponentSpace, and the "H" stands for the HistorySpace.
Note that IDs are bi-directionally encoded -- you can always recreate the slotPath from an ID and vice-versa.
Special characters in the slotPath are handled by replacing the "$" character with a "~" character. The sole exception to this rule is that "$20", which represents a single " " character, is replaced with a dash, "-", to improve the readability of the IDS. E.g:
If there is a site-equip-point hierarchy created in the station, then nhaystack will use that to generate the ID rather than the slotPath. E.g. if the SineWave in the first example was tagged up with an equip and a site, then its generated ID might look something like this:
In this case, there are actually two IDs that can be used to resolve the rec -- the slotPath version, and the Site-Equip-Point version.
Note that older versions of nhaystack used a Base64 encoding of the slot path, which looks something like this:
Nhaystack no longer generates IDs with this form, but it can resolve them.