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
I'd also suggest the new version to be completely domain agnostic in that all required information about the source and target data as well as queries can be provided separately (and thus packaged wherever dune-sync is deployed). The fact that for instance at the moment the app_hashes sql is checked into this repo, while the configuration of the sync job happens in the infrastructure repository is a smell imo.
I would suggest something like this as the general configuration shema:
[[datasources]]
name = "postgres"type = "postgres"url = "postgresql://host:port/?user=&password="
[[datasources]]
name = "dune"type = "dune"apikey = "xyz"
[[jobs]]
from = "dune"# referencing datasource nameto = "postgres"# referencing datasource namequery = 40000123# referencing dune query idtarget = "table"# referencing postgres target tabletruncate = false# if table should be truncated before
[[jobs.parameters]]
day = "2021-01-01"blockchain = "ethereum"
[[jobs]]
from = "postgres"to = "dune"query = "SELECT * FROM PRICES"# SQL query stringtarget = "table_name"# Dune table nameprivate = false# whether the dune table should be private or not
This way this client becomes a general purpose middleware for any web3 team that wants to bridge data in and out of Dune.
The text was updated successfully, but these errors were encountered:
It would be great to have a more generalised version of the dune-sync client that allows for both
Given that Dune has evolved and no longer recommends uploading data into S3 bucket it ingests, I'd suggest for 1) to mainly happen via the
upload_csv
functionality (as used in https://github.com/cowprotocol/dune-sync/blob/main/src/sync/app_data.py#L21).I'd also suggest the new version to be completely domain agnostic in that all required information about the source and target data as well as queries can be provided separately (and thus packaged wherever dune-sync is deployed). The fact that for instance at the moment the
app_hashes
sql is checked into this repo, while the configuration of the sync job happens in the infrastructure repository is a smell imo.I would suggest something like this as the general configuration shema:
This way this client becomes a general purpose middleware for any web3 team that wants to bridge data in and out of Dune.
The text was updated successfully, but these errors were encountered: