-
Notifications
You must be signed in to change notification settings - Fork 646
Description
Right now, each auth recipe (emailpassword, thirdparty..) has their own isolated users table. While paginating in them in isolation works fine, there is a problem when paginating in a recipe that combines the two - we have to manually create pagination tokens that work across both the recipes. This is complex, annoying and error prone
Core change
-
To fix this, we create one users table that can be shared across all auth recipes. This users table contains:
userId: string, timeJoined: number, createdByRecipe: string (recipeId)Using the above, pagination across users created from multiple recipes becomes very easy.
The API for this can take:
limit: number, // limit is max 500 nextPaginationToken?: string, includeRecipeIds?: string[] timeJoinedOrder?: "ASC" | "DESC"includeRecipeIdscan be used for pagination across only certain recipes. If this is missing, we paginate across all recipes. -
We need to create a global count API as well:
includeRecipeIds?: string[] -
Deprecate current getCount and pagination functions
Backend driver change
- We need to add one recipe independent pagination function
- We need to have one recipe independent get count function as well
- Deprecate current getCount and pagination functions
- Remove count and pagination functions from recipe implementation
Docs changes
- Change in recipe interface.
- API change for getCount and pagination functions in docs
- Adding values for
includeRecipeIdsin each recipe docs. - Change in value of limit
TODO:
- CDI change
- DB changes
- Do we need an index on
recipe_id? - Is our query optimal?
- we should filter based on timeJoined first and then based on recipeId
- sqlite
- postgresql
- mysql
- mongodb
- Do we need an index on
- API creation
- count
- pagination
- Testing core
- count
- pagination
- Backend SDK changes
- Testing backend SDK
- Docs:
- Add to CDI open API spec
- Add link in pagination docs (where it says TODO)