Avatar

upgrading from 5.6 to 5.7: question about Id

1

It's my understanding that...

  • Id contains Key and GUID.
  • Roughly half of the Geotab objects have been moved to GUIDs. 
  • If the object uses a GUID, the Id.GUID contains the value, while the Id.Key is null.
  • If the object uses a long, the Id.Key contains the value, while the Id.GUID is null.

So, I am doing our upgrade with the future migration to all GUIDs in mind. Will this pattern remain the same? Will the Id.Key eventually be null for all objects?

Mark Faucher

Please sign in to leave a comment.

6 comments

0
Avatar

Hi, 

In 5.7 all object are have there own Id, which is a long (or a string in javascript). So it is more simple to think about than how it was done in 5.6. For example an device object: myDevice, its Id would be myDevice.Id = 1. So just .Id contains the value

I hope I understand the question correctly 

Matt Claessens 0 votes
0
Avatar

That is not exactly what he is asking and I would like to know the answer to that also. 

The string Ids that are not guids in javascript are hex for the long value you would see in C#.

I got burned with the whole Entity Identifiers in the conversion.  I just simply convert the .Id value to a string now and try to stay away from the Id properties. 

 

Michael Head 0 votes
0
Avatar

Hi Guys,

Let me see if I can clear this up a bit. So while we plan on moving to all GUID's in the future, we also will not make any breaking changes to the API as it stands now. Changing the ID of an object you could be relying on would be a breaking change so we would not do this without some kind of backwards compatibility to ensure you're apps continue to run with no issue. It would likly mean using a different api end point (https://my.geotab.com/apiv2 or similar). In short, you should feel safe to work with ID as it sits now, knowing we won't just "flip a switch" and change an object from key to GUID breaking your application. I can't say how the ID object will look in the future, but it will not loose and properties in apiv1.

Steve

Steve Hansen 0 votes
0
Avatar

Thanks Steve, so this is a correct assumption for all objects, right?...

  • If the object uses a GUID, the Id.GUID contains the value, while the Id.Key is null.
  • If the object uses a long, the Id.Key contains the value, while the Id.GUID is null.
Mark Faucher 0 votes
0
Avatar

Steve - quick question. The 5.7 test db doesn't have customdata, so I can't figure out how to test this. Is CustomData.Id currently a guid, or is it still long?

Mark Faucher 0 votes