Skip to content
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

Allow using Bytes for ID and switch block explorer to that #1414

Closed
lutter opened this issue Dec 17, 2019 · 0 comments · Fixed by #1607
Closed

Allow using Bytes for ID and switch block explorer to that #1414

lutter opened this issue Dec 17, 2019 · 0 comments · Fixed by #1607

Comments

@lutter
Copy link
Collaborator

lutter commented Dec 17, 2019

Currently, the ID type for entities is always mapped to a String/text column in the database. For id's that are really hex strings/bytes that's wasteful as the string representation takes about 2x as much storage as a representation as Bytes/bytea.

The relational storage code has some provisions for using either String or Bytes, but they are not fully finished and tested. For the block explorer, we should switch id's to Bytes. To keep the changes in the rest of the code to a minimum, we will do this solely within the storage code. The rest of the code (when dealing with Entity) will still get a String id, though that is expected to be formatted as a hex string 0xdeadbeef...

The following needs to happen for that:

  • Make IdType an argument for Store::create_subgraph_deployment; the block explorer will pass IdType::Bytes there, while all other subgraphs will pass IdType::String
  • When a subgraph is started, look at information_schema.columns to decide whether the subgraph uses String or Bytes for ids
  • Fix up the places in relational_queries.rs that currently assume that ids are strings and write tests for that (mostly requires switching out.push_bind_param::<Text, _>(self.entity_id) to something better)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
1 participant