-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Rework generation of the VID #5737
base: zoran/rename-structs
Are you sure you want to change the base?
Rework generation of the VID #5737
Conversation
1bbef27
to
5910d01
Compare
632ef9f
to
9658d8c
Compare
9e6aa6d
to
02ce854
Compare
02ce854
to
62d1e2b
Compare
store/postgres/src/relational/ddl.rs
Outdated
@@ -116,19 +116,26 @@ impl Table { | |||
Ok(cols) | |||
} | |||
|
|||
let vid_type = if self.object.is_poi() || !self.object.is_object_type() { |
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.
@lutter I am not sure which types could have the VIDs still autogenerated as before. Here I choose POI, interface and aggregate types. Is this correct?
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.
Strictly speaking, for POI it doesn't matter, and there's never instances of interfaces (only objects that implement an interface), but I think for simplicity, it might be best to autogenerate a vid for every kind of entity we deal with.
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.
So you would prefer that all is generated by us rather than from the database? Is there inconsistency concern regarding the aggregation (that one is more involved)?
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.
There is a PR #5770 that disables aggregations entities as source entities for now.
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.
A general question: we already require that every Entity
has an id
, if it doesn't, things will fail in funky ways. Wouldn't it be simpler to just treat the vid
as another attribute of Entity
, i.e., require that entity.get("vid")
always returns something instead of keeping it separate from the entity?
store/postgres/src/relational/ddl.rs
Outdated
@@ -116,19 +116,26 @@ impl Table { | |||
Ok(cols) | |||
} | |||
|
|||
let vid_type = if self.object.is_poi() || !self.object.is_object_type() { |
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.
Strictly speaking, for POI it doesn't matter, and there's never instances of interfaces (only objects that implement an interface), but I think for simplicity, it might be best to autogenerate a vid for every kind of entity we deal with.
70a0f32
to
6e5b0bc
Compare
b6f7492
to
640e7d1
Compare
@lutter I've decided to go that route. It simplifies the code a lot. Also I've added a check in the Finally when deserializing the entities from the database, I added deserialization of the the Those are two major changes since your last review. |
6feee8e
to
14671db
Compare
14671db
to
640e7d1
Compare
14671db
to
640e7d1
Compare
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.
This looks good. I'd mostly just like to understand better what is happening with the explicit block number for the PoI.
Also, I don't think there are any tests that ensure that the vid's are indeed set by insertion order. It would be good to have a test for the EntityCache
that ensures that.
/// Sets the VID of the entity. The previous one is returned. | ||
pub fn set_vid(&mut self, value: i64) -> Result<Option<Value>, InternError> { | ||
self.0.insert("vid", value.into()) | ||
} |
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.
One additional thought: it would be great if we could guarantee that an entity is always constructed with the vid
set, similar to how that's done for the id
. I haven't checked how much work that is, but it would make the various expects sprinkled around here easier to accept.
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 like the suggestion but would like to postpone it together with the testing request above for a later stage. WDYT?
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.
The test for the VID order is implemented now: 166c909
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 am fine with postponing the enforcement of having a vid
961556b
to
a49edb8
Compare
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.
Nice! I left some minor stylistic comments, would be great to address them, but I am totally fine with merging this.
9658d8c
to
cca4d6f
Compare
e61452f
to
1cb3401
Compare
7173051
to
46fa0f4
Compare
46fa0f4
to
061b9c7
Compare
This PR changes the generation of the VID in such a way that entities have an order determined by the order of the blockchain transactions from which they originate, rather than to be ordered by the current implementation of the graph-node and the VID autogenerated by the database. This in turn will ensure that the dependant subgraphs would have a deterministic order of their input entities and it would be consistent across different graph-node deployments producing the same POI.