You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Issue
We need to first settle on the user stories / user experiences we intend to deliver with respect to account management. This is not necessarily an exhaustive list of things to consider, but a few that we've run up against that require some thought, requirements setting, and then implementation include:
setting and updating a user's "primary address"; currently the wallet address of user's first connected wallet becomes a new user on the users table with address being the pk. We should figure out what the best practice should be if we were to update that "primary address" to something else.
determining if multiple users can share addresses; currently address is the pk on accounts table, so even if two accounts have different owner_addresses (fk to users table), we'd cause a pk collision on the accounts table with our current schema if we were to enable this
implement a base type naming convention where base types are derived from PG table schema, which then allows us to extend names of the base types with descriptive names to be used in application code
Solution
Determine user story --> user experience --> requirements and write them here. Then implement.
Further Info
I'll be handling this task, but I think everyone will be affected by its outcome so tagging you all (@shanejearley@hawyar@DemogorGod) for awareness. I welcome all thoughts, comments, and feedback, but don't feel obligated. Will run my thought process by at least one of you before implementing.
The text was updated successfully, but these errors were encountered:
Issue
We need to first settle on the user stories / user experiences we intend to deliver with respect to account management. This is not necessarily an exhaustive list of things to consider, but a few that we've run up against that require some thought, requirements setting, and then implementation include:
users
table withaddress
being thepk
. We should figure out what the best practice should be if we were to update that "primary address" to something else.address
is thepk
onaccounts
table, so even if two accounts have differentowner_address
es (fk
tousers
table), we'd cause apk
collision on theaccounts
table with our current schema if we were to enable thisPG
table schema, which then allows us to extend names of the base types with descriptive names to be used in application codeSolution
Determine user story --> user experience --> requirements and write them here. Then implement.
Further Info
I'll be handling this task, but I think everyone will be affected by its outcome so tagging you all (@shanejearley @hawyar @DemogorGod) for awareness. I welcome all thoughts, comments, and feedback, but don't feel obligated. Will run my thought process by at least one of you before implementing.
The text was updated successfully, but these errors were encountered: