-
Notifications
You must be signed in to change notification settings - Fork 987
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
Derived fields getter #4434
Derived fields getter #4434
Conversation
I splitted and renamed the structs for a more semantic naming and usage. |
@lutter do you think the implementation for the |
Sorry, I completely missed that. Yes, we do need the implementation for From a quick glance at your last commit, it looks like you figured out what needs to happen: the query needs to be run against the store and the result needs to be updated according to the changes still in the queue similar to what I'll try and review what you have in the next few days. |
259b2be
to
173b32a
Compare
Yes, I figured out! The only point of optimization is to filter in the database query the entities ids that we already have from queue so we can save some cpu clocks. |
3d9a5b0
to
734cbb4
Compare
@lutter I did some optimizations with the query but I would be more secure if I could test it. Do you have any suggestions where I can place the tests for it? |
6b7ae9a
to
c920ff2
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 all looks very good. There is one issue in writable.rs
that needs to be addressed and a few small stylistic comments.
graph/src/data/schema.rs
Outdated
@@ -643,6 +643,43 @@ impl Schema { | |||
} | |||
} | |||
|
|||
pub fn get_type_for_field(&self, key: &LoadRelatedRequest) -> Result<(&str, &str), Error> { |
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 think it would be clearer here if the second entry in the tuple was a &Field
- would be nice to make the first one an ObjectType
but that would require serching the schema for that, and that doesn't seem worth the effort.
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.
How is this extensible when we start to use non-derived fields? Is there any &Field
that represent the relationship between the parent and the child?
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.
Yes, the difference is that with a derived field the schema looks like
type Parent {
children [Child!]! @derivedFrom(field: "parent")
}
and for a non-derived field it is
type Parent {
children [Child!]!
}
In that case, the parent has a column children
of either type text[]
or bytea[]
depending on the type of Child.id
I think the best place for tests would be in |
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.
Apart from the small type for derivedFrom
, this looks good. I just realized that this PR does not take one other situation into account: the field that is mentioned in the @derivedFrom
can also be an array. This document goes through all the possible permutations. But I would also rather address this in a follow-on PR; I believe that taking that into account only requires some small changes to the query generation logic.
wow, I didn't know that. Everything that I know about subgraphs was reading the Official documentation and it doesn't have anything related to I'll look through the document you sent and, if it is the case, try to fail gracefully until the follow-on PR. |
This all looks good now. @azf20 I forget, what is the process for adding a new host function? I think we need to add a API version 0.0.8 and make sure the new host function is only available with that version? |
@flametuner can you rebase to latest master? |
Nice! Process depends on what the functionality is exactly, I think indeed in this case we probably need a new apiVersion, but cc @leoyvens who can confirm what check we then also need on |
@lutter I added some tests. I found a bug while testing and fixed it in |
705af40
to
ee6f225
Compare
@lutter is there anything blocking this PR? Please let me know so I can fix it. |
This all looks good - can you rebase once more? I can then merge it. |
96de2db
to
1cbb1ea
Compare
@flametuner I think it needs a little bit of additional work - most of the CI checks are failing |
Rebase didn't update some errors types in my code. Just fixed that. |
d112905
to
ceeeb96
Compare
rename variables to be more meaningful
runtime: fix rebase problem
ceeeb96
to
196c36e
Compare
@flametuner Thanks a ton for this PR. Great work! |
This PR aims to add a getter for
derivedFields
. Fixes #4004Roadmap
store.loadRelated
host functionfind_derived