-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add database setup #74
Changes from 2 commits
d188824
fbced8a
a14969d
4fe802b
8f55892
567fd0b
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,4 @@ | ||
FROM postgres | ||
ENV POSTGRES_PASSWORD postgres | ||
ENV POSTGRES_DB mainnet | ||
COPY ./database/01_table_creation.sql /docker-entrypoint-initdb.d/ |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,23 @@ | ||
CREATE TABLE token_info ( | ||
token_address bytea PRIMARY KEY, | ||
symbol varchar NOT NULL, | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Tbh the symbol is not needed, so i would remove it (as i am also always nervous with the crazy characters some tokens use that might cause encoding issues here). And if you want to include it, i would definitely make it optional There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Then lets just remove it. No need to store unused data here. |
||
decimals int NOT NULL | ||
); | ||
|
||
CREATE TABLE token_times ( | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I find the name a bit unintuitive. I would probably change it to something like
or There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Would This table is not about imbalances and There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Hm, then what is it about? There is a tx hash associated with each entry There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I added a clarification in the comment above.
Maybe the clean design would be to have a There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yeah, the distinction between the |
||
time timestamp NOT NULL, | ||
token_address bytea NOT NULL, | ||
block_number bigint NOT NULL, | ||
tx_hash bytea NOT NULL, | ||
|
||
PRIMARY KEY (time, token_address, tx_hash) | ||
); | ||
|
||
CREATE TABLE prices ( | ||
time timestamp NOT NULL, | ||
token_address bytea NOT NULL, | ||
price numeric(60, 18) NOT NULL, | ||
source varchar NOT NULL, | ||
|
||
PRIMARY KEY (time, token_address, source) | ||
); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't we make it chain-specific? I would rename it to
token_info_mainnet
given that we will probably use one version of the db for all chains
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why would we have one database for all chains instead of one database per chain? We use the latter for all other purposes.
If we go with having information on all chain in one database, I would expect that having an additional column
network
in all tables is better that duplicating tables for each chain.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't have a strong opinion here, but this would add overhead, as we (i.e., devops) would need to set up different databases, accounts etc
Although postgres most likely takes care of everything, having a single table where multiple daemons might try to add things at the same time could create some race conditions. Also, could it make things slower, as network should be part of the primary key now?
Somehow having a separate table per chain looks safer/more flexible.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you think, @ahhda?