Bugzilla

Sure,

so in the case of going to option 3, whether you change just the metric type or it's name, you would have to access data a bit differently because data would no longer be flowing into the `metrics.string.gfx_adapter_primary_description` (note the `string` part of that re changing type) field in SQL. So, for example, if you had your own queries, looker looks, dashboards etc. that used this, they would have to be updated or you would only get data through versions where that metric was still sent by that exact collection. You all would know if you have that sort of thing, but it's worth noting that those things might be impacted should they exist.

Typically speaking, we recommend that if you need to change the type, you go ahead and create a new collection. That collection can have a name and description that clarify why it's there. In theory, you could continue to have a smaller version of this field continue to flow into the existing metric, and have an expanded one of type `text` if you liked.

If you feel that 

>On Android it is a combination of several Android SDK Build constants, as well as the OpenGL Renderer, Vendor, and Version strings

is still something you need, this would be a good candidate for that new collection. You could then update the recording of the android value into `gfx_adapter_primary_description` to be something that wouldn't overflow.

Sure,

so in the case of going to option 3, whether you change just the metric type or it's name, you would have to access data a bit differently because data would no longer be flowing into the `metrics.string.gfx_adapter_primary_description` (note the `string` part of that re changing type) field in SQL. So, for example, if you had your own queries, looker looks, dashboards etc. that used this, they would have to be updated or you would only get data through versions where that metric was still sent by that exact collection. You all would know if you have that sort of thing, but it's worth noting that those things might be impacted should they exist. On our end, we would be a bit concerned about Glean Dictionary as well, so _only_ updating the type is not the best way to go here.

Typically speaking, we recommend that if you need to change the type, you go ahead and create a new collection. That collection can have a name and description that clarify why it's there. In theory, you could continue to have a smaller version of this field continue to flow into the existing metric, and have an expanded one of type `text` if you liked.

If you feel that 

>On Android it is a combination of several Android SDK Build constants, as well as the OpenGL Renderer, Vendor, and Version strings

is still something you need, this would be a good candidate for that new collection. You could then update the recording of the android value into `gfx_adapter_primary_description` to be something that wouldn't overflow.