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

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 

0
Comment actions Permalink
Matt Claessens 0 votes
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. 

 

0
Comment actions Permalink
Michael Head 0 votes
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

0
Comment actions Permalink
Steve Hansen 0 votes
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.
0
Comment actions Permalink
Mark Faucher 0 votes
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?

0
Comment actions Permalink
Mark Faucher 0 votes