Inconsistent types in multiwatcher return values

[Jeff Pihach]

The `id` in relation info is an `int`

https://github.com/juju/juju/blob/develop/apiserver/params/multiwatcher.go#L322

But it's a number as a `string` everywhere else.

https://github.com/juju/juju/blob/develop/apiserver/params/multiwatcher.go#L295

[Ian Booth (wallyworld)]

Relation IDs are ints in the data model. They start at 1 and go up from there. Relations also have a "key" which is a string, and it's this value which we map onto the generic entity ID value

https://github.com/juju/juju/blob/develop/apiserver/params/multiwatcher.go#L353

Action IDs started out as strings - UUIDs in fact. We recently transitioned to using a numeric sequence as for relations but for compatibility need to retain the type as a string as there could still be older actions with UUIDs in the model.

So the multiwatcher types in the params structs for relations and actions are correct according to the requirements of the types used for the respective IDs. We will probably transition to using ints for action IDs in Juju 3 where we can break compatibility.

Note though that as a general rule, there's no requirement that different entities should model their IDs using the same type. Having said that, I wish we had bettered modelled the difference between database key (which should be opaque and consistent, either string or int), and natural key (machine name, application name etc). Sadly natural key and database key are often one and the same.

[John A Meinel (jameinel)]

It is an interesting question. Do we want to say "all interactions with the API will have a handle for an object which is a string". Certainly you can encode any other object into a string (int=>str is an obvious one).
I do know there are several things that we track explicitly as integers (relation ids, new action ids, etc). But there are also things that are 'almost integers'. Machines are integers, but containers are also a form of machine, and there handle is a path (0/lxd/0)

I think there are a small handful of things that are genuine integers.

Much of the API actually deals in "Tags" which must be strings, as they prefix with the context (machine-0, unit-apache-2, etc).
I'm a little curious why we wouldn't have contextualized the relation requests.