How to retrieve trait keys with the Global API

[dabeeeenster]

Because of the way we are storing Identity Trait data in DynamoDB, it's not possible to do something like SELECT DISTINCT trait_key FROM Traits to get a list of keys. This list is currently used on the Identities page, but also is required for #343.

One possible solution to this would be to sample a random list of Identities (e.g. 20 identities) and build the distinct Trait Key list based on those 20 identities. This would be fast, and would get us a set of data, but it could miss trait keys if some Identities have that key defined and some don't. Having a list of some keys would be better than nothing for #343 but it might be odd showing a list of keys with a message "this might be missing some keys".

We could persist that list in the postgres database and update it over time. This would reduce the likelihood of missing Keys, but could then show keys that have subsequently been deleted.

Open to other ideas!

[matthewelwell]

Yeah, I don't really see another option than storing this disctinct list somewhere (postgres or elsewhere). There are a few considerations though.

When do we store / delete each key?

### 1. Do it every time an identity gets stored

The problem with this approach is that identities are (99 times out of 100) stored when a request comes in from a client SDK, we ideally don't want to add any latency there.

### 2. Do it every time an environment gets stored

The problem with this is that it would mean grabbing all the identities for that environment and iterating over them - probably not very efficient. We'd need to look into paging within dynamo lest we hit a memory issue for environments with large amounts of identities I would imagine. The benefit is environments are only stored from the dashboard.

### 3. Do it on trait create / delete (using a lifecycle hook)

This is probably the cleanest but again would affect the time sensitive SDK endpoints.

Where do we store them?

We would also need to consider where this gets stored. If we want to store it in Postgres, we'd want to create a Django model for it. The model would be pretty simple, just trait_key and environment_id (or project_id - not sure what level we want to store these at) I would imagine but it seems a bit backwards to have that level of denormalisation in our Django models. Another option would be to store it in some separate cache layer somewhere but this would introduce additional hosting complexity.

Perhaps a good compromise would be to look into using the django db caching functionality?

[gagantrivedi]

3. Do it on trait create / delete (using a lifecycle hook)

This is probably the cleanest but again would affect the time sensitive SDK endpoints.

Are we talking about storing traits in django db here? because traits can be set using sdk endpoints as well, right?