deviationsrawdata returned 2 different entries for same ID
Hej dear SL-team!
Today happened something weird when I fetched data from the deviationsrawdata endpoint. 2 Entries that had the same ID (9076001011616288) had different messages.
As far as I know the entries can be summed up by their DevCaseGid to get all the lines and SiteIds which are affected by this incident. But in this case it seems that there are 2 incidents filed under the same ID.
Am I using this API wrong and having the wrong conclusions or is this a bug?
Please find here the data in question:
(the same thing happened a couple of days ago with the ID 9076001011602180 but I did not paste the data for this ID here)
[{
SiteId: null,
Updated: '2017-08-28T17:07:11.48+02:00',
DevMessageVersionNumber: 1,
Priority: 21,
SortOrder: 1,
DevCaseGid: 9076001011616288,
LineNumber: '810',
Created: '2017-08-28T17:07:11.48+02:00',
Details: 'Försening upp till 15 minuter för buss 810 från Gullmarsplan kl 16:24 mot Västerbommen på grund av hög belastning.',
Header: 'Försenad avgång',
Scope: 'Buss 810',
UpToDateTime: '2017-08-28T17:33:00',
ScopeElements: 'Buss 810',
TransportMode: 'BUS',
MainNews: false,
FromDateTime: '2017-08-28T16:16:00'
},
{
SiteId: null,
Updated: '2017-08-28T17:07:12.78+02:00',
DevMessageVersionNumber: 1,
Priority: 9,
SortOrder: 1,
DevCaseGid: 9076001011616288,
LineNumber: '926',
Created: '2017-08-28T17:07:12.78+02:00',
Details: 'Försening på 11 minuter för buss 26 från Solsidans station kl 16:56 mot Slussen på grund av bilköer.',
Header: 'Försenad avgång',
Scope: 'Buss Ersätter Saltsjöbanan 926',
UpToDateTime: '2017-08-28T18:01:00',
ScopeElements: 'Buss 926',
TransportMode: 'BUS',
MainNews: false,
FromDateTime: '2017-08-28T16:36:00'
}]
Thank you very much for your help!
Matthias
Today happened something weird when I fetched data from the deviationsrawdata endpoint. 2 Entries that had the same ID (9076001011616288) had different messages.
As far as I know the entries can be summed up by their DevCaseGid to get all the lines and SiteIds which are affected by this incident. But in this case it seems that there are 2 incidents filed under the same ID.
Am I using this API wrong and having the wrong conclusions or is this a bug?
Please find here the data in question:
(the same thing happened a couple of days ago with the ID 9076001011602180 but I did not paste the data for this ID here)
[{
SiteId: null,
Updated: '2017-08-28T17:07:11.48+02:00',
DevMessageVersionNumber: 1,
Priority: 21,
SortOrder: 1,
DevCaseGid: 9076001011616288,
LineNumber: '810',
Created: '2017-08-28T17:07:11.48+02:00',
Details: 'Försening upp till 15 minuter för buss 810 från Gullmarsplan kl 16:24 mot Västerbommen på grund av hög belastning.',
Header: 'Försenad avgång',
Scope: 'Buss 810',
UpToDateTime: '2017-08-28T17:33:00',
ScopeElements: 'Buss 810',
TransportMode: 'BUS',
MainNews: false,
FromDateTime: '2017-08-28T16:16:00'
},
{
SiteId: null,
Updated: '2017-08-28T17:07:12.78+02:00',
DevMessageVersionNumber: 1,
Priority: 9,
SortOrder: 1,
DevCaseGid: 9076001011616288,
LineNumber: '926',
Created: '2017-08-28T17:07:12.78+02:00',
Details: 'Försening på 11 minuter för buss 26 från Solsidans station kl 16:56 mot Slussen på grund av bilköer.',
Header: 'Försenad avgång',
Scope: 'Buss Ersätter Saltsjöbanan 926',
UpToDateTime: '2017-08-28T18:01:00',
ScopeElements: 'Buss 926',
TransportMode: 'BUS',
MainNews: false,
FromDateTime: '2017-08-28T16:36:00'
}]
Thank you very much for your help!
Matthias
Följ inlägget
0
följare
Thank you for your question.
This is a known issue due to the fact that JavaScript/Json cannot handle/parse large integer values very well.
Example:
> parseInt("10765432100123456789") will give 10765432100123458000
You can read about the problem as described here:
https://cdivilly.wordpress.com/2012/04/11/json-javascript-large-64-bit-integers/
DevCaseGid values are in fact correct (and different) if you would analyze the RAW HTTP body content of the response.
Unfortunately, I don’t know any quick solution to solve the problem in JavaScript. One possible way is to parse the HTTP response body in other language, like C# or Java, to get the proper values.
The long-term solution would be as follows:
This API need to change its specification and redefine the DevCaseGid property as String type, instead of JavaScript Number, to avoid possible precision loses for 64-bit integers values in the JavaScript language.
I hope you have now a clearer understanding of your case.
It completely slipped my mind that it could be this problem... Thanks for pointing it out.
Just for documentation (in case someone else is having the same problem), I came up with 2 solutions:
Nr 1: Regex
This is very hacky but it works. Just use regex to create a string from this number in the raw json string before parsing:
const regex = /"DevCaseGid":\s*(\d+)/g;
const str = `"Scope": "Förändringar för linje 731 från och med 25 janurari","DevCaseGid": 9076001010498914,"DevMessageVersionNumber": 1,`;
const subst = `"DevCaseGid":"$1"`;
// The substituted value will be contained in the result variable
const result = str.replace(regex, subst);console.log('Substitution result: ', result);
Nr 2: Library
In case you are using node.js you can also use a different JSON parser library that actually supports these long integers:
https://www.npmjs.com/package/json-bigint
So is this number really a unique ID? How is this generated? Is it an autoincrement ID from a database or is there a chance that a ID will be reused after some time?
Thanks!
Matthias