Previously the function used to upsert into the user dimension required
both an auth token id, and a user id. However, the user id can be
determined from the auth token, in fact it already was via the
whx_user_dimension_source view. This refactor removes the user id as an
argument, since it is not needed and will not be directly available when
this function is used when populating the new auth token accumulating
fact.
Ensure the new create_time and update_time columns
are marked as not null after populating the data.
Also ensure that the data is populated safely with an
updated query pattern inspired by the auth method
pattern.
* wip
* implement list pagination for auth methods
* remove unused code
* update tests to fix sorting
* address PR comments
* simplify query, add token tests
* change test name
* wip sql testing
* add boolean column to indicate whether auth methods should be returned to unauthenticated users, remove secrets from api response
* is_active_public not null
* remove secrets and unwrapping
* move not null to immediately after data migration
* order public_id descending
* fix(db): Fix auth method migrations (#4193)
* wip
* fix db tests
* fix failing api tests
* reverse order of create time and update time in test
---------
Co-authored-by: Michael Gaffney <mike@gaffney.cc>
The previous sort would run the risk of missing items which
collide on update or create times because of the compound
comparison using strictly less than for both the timestamp
and the public_id. Sorting both descending avoids this issue.
The previous sort would run the risk of missing items which
collide on update or create times because of the compound
comparison using strictly less than for both the timestamp
and the public_id. Sorting both descending avoids thi issue.
The previous sort would run the risk of missing items which
collide on update or create times because of the compound
comparison using strictly less than for both the timestamp
and the public_id. Sorting both descending avoids thi issue.
The previous sort would run the risk of missing items which
collide on update or create times because of the compound
comparison using strictly less than for both the timestamp
and the public_id. Sorting both descending avoids thi issue.
The previous sort would run the risk of missing items which
collide on update or create times because of the compound
comparison using strictly less than for both the timestamp
and the public_id. Sorting both descending avoids thi issue.
The previous sort would run the risk of missing items which
collide on update or create times because of the compound
comparison using strictly less than for both the timestamp
and the public_id. Sorting both descending avoids thi issue.
The previous sort would run the risk of missing items which
collide on update or create times because of the compound
comparison using strictly less than for both the timestamp
and the public_id. Sorting both descending avoids thi issue.
* Add pagination support for auth tokens
* change analyze count estimate comment
* adjust queries for efficiency and security
* even more efficient queries
Timothy Messier
Jeff MitchellandDamian Debkowski
Johan Brandhorst-Satzkorn
Louis Ruch
Jim
Danielle Miu
Hugo
Michael Milton
