Would it make sense to move id_attribute from provider to resource?

[rberlind]

It occurs to me that if you moved id_attribute from the provider to the resource, then multiple resources with different values of this setting could be created against a single instance of the provider. Would that make sense? Or is there some reason it needs to be on the provider itself?

[DRuggeri]

The id_attribute is set at the provider level, but is used at the resource level. When an object is created and returns:

{
  "id": "foo",
  "name": "bar",
. . . 
}

the internal terraform ID of that object will be just foo and subsequent calls to the API (unless messing with *_path) will go to [value_of_path]/foo

This is set at the provider level since it's a reasonable assumption that the attribute used to identify an object is going to be the same attribute across all objects.

I think it would be more aligned with "terraform-isms" to create multiple provider instances if the API does such a strange thing.

[DRuggeri]

Does this address the question sufficiently enough to close the issue, @rberlind?

[rberlind]

Using multiple provider instances could certainly be done and would be needed for other reasons such as using the provider in a single Terraform configuration against multiple API servers.

I don't agree that the ID would be the same for all objects even if hitting a single API server. Different APIs within a single API server might use different field for ID. For instance, the Terraform Enterprise API uses "name" to retrieve a specific workspace whereas most of its other API endpoints use "id". Compare https://www.terraform.io/docs/enterprise/api/workspaces.html#update-a-workspace and https://www.terraform.io/docs/enterprise/api/policies.html#update-a-policy. The first requires specifying the workspace name instead of the id (which does exist) while the second requires specifying the id itself.

It also turns out that datasources as currently written need id_attribute to be set. If different datasources wanted to use a different field as the "id", being able to set it in both the resource and in the datasource would avoid having to use multiple instances of the provider unless absolutely necessary.

Perhaps it would make sense to add id_attribute field to both the resource and datasource schemas and have those override id_attribute set in the provider if set? That way, a user who did have the same id_attribute for all API endpoints on a single API server would only need to set it once, at the provider level; but users who needed different id_attributes could override the value that had been set in the provider itself? I might be able to try adding this.

Making this change is certainly not urgent. As you said, multiple provider instances can always be used.

[DRuggeri]

SO sorry for the long delay. Thinking more about it, id_attribute really is an object-level construct anyway. I've done as you suggest and made the value available in the resource, datasource AND provider. If all of the objects will work the same, it's easier/more user friendly to set it on the provider. Otherwise, each resource/datasource can have it's own distinct setting now as of 1.3.0.

[rberlind]

Awesome. Thanks. I do think the extra flexibility will be useful.

[DRuggeri]

Cool - we'll call it good and close this one out.

[rberlind]

Thanks!