List all partition keys of an application

[shun-liang]

Is your feature request related to a problem? Please describe.
Right now, burr does not provide an interface to list all partition_keys of an application.

Quoting from the documentation:

In the case of a chatbot, the app_id could be a uuid, and the partition_key could be the user’s ID or email, etc. Note that partition_key can be None if this is not relevant. A UUID is always generated for the app_id if not provided.

Imagine we are implementing an admin page for the system managing the chatbot, and need to display all the users' chat sessions, that the interface to retrieve all the partition_keys from an application should become necessary.

Describe the solution you'd like
Maybe a method from the application to retrieve all the partition_keys?

Describe alternatives you've considered
Direct data retrieval from the storage where the states of the application are persisted.

Additional context
None

[skrawcz]

@shun-liang question, what filters would you want if any on this? I'm just thinking ahead because all partition keys could be expensive in certain situations.

E.g. get me active ones since X timestamp, or get me all created since X timestamp, etc.

Alternatively, you could manage this in a datastore/database outside of Burr.

[shun-liang]

what filters would you want if any on this?

I would imagine it being very integral with the state, maybe something like how a condition is defined?

I'm just thinking ahead because all partition keys could be expensive in certain situations.

Indeed this can be the case. In the end the users needs to be well aware of the pros and cons choosing the persistance backend, but maybe burr as the library can provide opinions and advices in the doc?

Alternatively, you could manage this in a datastore/database outside of Burr.

True. However this does require the user to dig into the persister implementation to understand they work.

[skrawcz]

True. However this does require the user to dig into the persister implementation to understand they work.

I was thinking you'd maintain a separate DB table, or something separate from the persister. E.g. something tied together/closer to your authentication system. Since generally the parition_key should map to some "user Id" or other identifier. In which case you could then use that to figure out what partition_keys would exist.

[skrawcz]

what filters would you want if any on this?

I would imagine it being very integral with the state, maybe something like how a condition is defined?

Oh interesting. That might be too slow since we'd be dealing with serialized data (we'd have to think about custom indexes or some other data structure to help facilitate this). My first thought was around timestamps at the minimum.

[elijahbenizzy]

what filters would you want if any on this?

I would imagine it being very integral with the state, maybe something like how a condition is defined?

Oh interesting. That might be too slow since we'd be dealing with serialized data (we'd have to think about custom indexes or some other data structure to help facilitate this). My first thought was around timestamps at the minimum.

IMO it's more likely that you'd want a paginated API -- E.G. a way to grab the first 100 users, etc... Then you'll also want a way to search for users. For less than, like, 100k, you can likely send them all over the wire and process it client-side, so it might be that just a list_all is good.