-
Notifications
You must be signed in to change notification settings - Fork 996
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
#1445
Conversation
f889b25
to
71f42ed
Compare
Rebased to latest master |
The correct IdType is closely tied to the subgraph and its schema - ultimately, we need the user to tell us whether their subgraph is suitable for using IdType::Bytes. This change only puts the plumbing in place to do so; we still use IdType::String for all subgraphs.
The metadata subgraph has two tables: entities and entity_history. The latter has a column `id` of type `integer`, and we can therefore not use information_schema to determine whether the subgraph uses `String` or `Bytes` for the primary key
For JSONB storage, we have one table with a `text` id, and one with an `int` id; depending on which one we saw first, we might get confused. Instead, special-case JSONB storage and report that it uses `IdType::String`
b67f0a2
to
2654726
Compare
Rebased to latest master |
@@ -180,6 +180,18 @@ mod public { | |||
state -> crate::entities::public::DeploymentSchemaStateMapping, | |||
} | |||
} | |||
|
|||
// Access to the bits of the information_schema we care about. It conists |
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.
Typo: conists -> consists
"bytea" => IdType::Bytes, | ||
_ => { | ||
return Err(StoreError::Unknown(format_err!( | ||
"unsupported type `{}` for primary key column in table {} in schema {}(`{}`)", |
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 put ``
around the table {}
placeholder too?
pub enum IdType { | ||
String, | ||
#[allow(dead_code)] | ||
Bytes, |
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.
Interesting, I didn't know you had already prepared this. 😉
let bytes = scalar::Bytes::from_str(&s) | ||
.map_err(|e| DieselError::SerializationError(Box::new(e)))?; |
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.
Isn't this identical to the new str_as_bytes
helper?
scrubbed | ||
} | ||
|
||
macro_rules! assert_entity_eq { |
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.
I have nothing against macros, but this to me looks like it could also just be a regular function; unless I'm missing something?
Map between strings that represent bytes and
bytea
in the database; the difference between subgraphs that useBytes
forID
and those that useString
is transparent to subgraph users. The only exception is that when an entity is stored with an id0xdeadbeef
it will be returned as the stringdeadbeef
stripping the0x
prefix.Currently, this is only used for network indexing; all user-supplied subgraphs still use
String
as theirID
and there is no way for users to switch toBytes
.Fixes #1414