In the graph of the current schema, the Account and Transaction entities could be sharing an edge as the Transaction entity already contains a signerAddress field which would accurately represent this as a foreign key. I think this is more accurate representation of the graph and increases ease of use of and reasoning about the API. I see two options to establish this edge:
Using signerAddress directly as the foreign key
breaks convention in naming the field after the related model
is backwards incompatible (i.e. would have to be included in v1.x release if we wanted to do it)
Add new field
duplicates account ID scaling with number of indexed transactions
can deprecate signerAddress in a future release
good excuse to prioritize putting a plan together for deprecation
it's likely going to be difficult to avoid entirely despite graphql's flexibility
Changes
Going for option 2:
adds account field to the Transaction entity which relates to the Account entity
updates entity relation diagrams
Depends on / TODO
229
After #229 is merged, to rebase onto main run:
# assumes remote is named "origin", substitute if not
git fetch origin
git checkout chore/account-primitive
# assumes remote is named "origin", substitute if not
git rebase --onto origin/main origin/refactor/python-models chore/account-primitive
git push --force-with-lease origin chore/account-primitive
Code Review Checklist (to be filled out by reviewer)
[ ] Description accurately reflects what changes are being made.
[ ] Either the PR references an issue (via the "Development" combobox) or the description explains the need for the changes.
[ ] The PR appropriately sized.
[ ] The PR contains an idempotent DB migration.
[ ] I have verified the correctness of the DB migration using relevant data (e.g. test-generated data).
[ ] New code has enough tests.
[ ] New code has enough documentation to answer "how do I use it?" and "what does it do?".
[ ] Existing documentation is up-to-date, if impacted.
Rationale
In the graph of the current schema, the
Account
andTransaction
entities could be sharing an edge as theTransaction
entity already contains asignerAddress
field which would accurately represent this as a foreign key. I think this is more accurate representation of the graph and increases ease of use of and reasoning about the API. I see two options to establish this edge:signerAddress
directly as the foreign keysignerAddress
in a future releaseChanges
Going for option 2:
account
field to theTransaction
entity which relates to theAccount
entityDepends on / TODO
229
After #229 is merged, to rebase onto main run:
Code Review Checklist (to be filled out by reviewer)