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

Derived fields getter #4434

Merged
merged 22 commits into from
Mar 29, 2023
Merged

Derived fields getter #4434

merged 22 commits into from
Mar 29, 2023

Conversation

gusinacio
Copy link
Contributor

@gusinacio gusinacio commented Mar 8, 2023

This PR aims to add a getter for derivedFields. Fixes #4004

Roadmap

  • add store.loadRelated host function
  • create query for find_derived
  • retrive derived entities from the database
  • create ASC conversion
  • get derived from queue
  • optimize the get derived query to filter entities ids
  • tests

@gusinacio gusinacio changed the title WIP: Derived getter WIP: Derived fields getter Mar 8, 2023
@gusinacio gusinacio marked this pull request as draft March 8, 2023 16:22
@gusinacio
Copy link
Contributor Author

I splitted and renamed the structs for a more semantic naming and usage.

@gusinacio
Copy link
Contributor Author

@lutter do you think the implementation for the Queue with a Writer::Async is needed? And if so, how do you suggest to implement?

@lutter
Copy link
Collaborator

lutter commented Mar 14, 2023

@lutter do you think the implementation for the Queue with a Writer::Async is needed? And if so, how do you suggest to implement?

Sorry, I completely missed that. Yes, we do need the implementation for Writer::Async - that is now the main way how changes get written. The implementation Writer::Sync is only there as a safety measure in case we discover bugs with Writer::Async, and we could probably remove it at this point.

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 get and get_many do.

I'll try and review what you have in the next few days.

@gusinacio
Copy link
Contributor Author

gusinacio commented Mar 14, 2023

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 get and get_many do.

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.

@gusinacio gusinacio force-pushed the derived-getter branch 2 times, most recently from 3d9a5b0 to 734cbb4 Compare March 15, 2023 15:01
@gusinacio
Copy link
Contributor Author

@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?

@gusinacio gusinacio changed the title WIP: Derived fields getter Derived fields getter Mar 16, 2023
@gusinacio gusinacio marked this pull request as ready for review March 16, 2023 18:09
Copy link
Collaborator

@lutter lutter left a 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.

runtime/wasm/src/module/mod.rs Outdated Show resolved Hide resolved
runtime/wasm/src/module/mod.rs Outdated Show resolved Hide resolved
graph/src/data/schema.rs Show resolved Hide resolved
@@ -643,6 +643,43 @@ impl Schema {
}
}

pub fn get_type_for_field(&self, key: &LoadRelatedRequest) -> Result<(&str, &str), Error> {
Copy link
Collaborator

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.

Copy link
Contributor Author

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?

Copy link
Collaborator

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

store/postgres/src/writable.rs Show resolved Hide resolved
store/postgres/src/relational.rs Outdated Show resolved Hide resolved
@lutter
Copy link
Collaborator

lutter commented Mar 16, 2023

@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?

I think the best place for tests would be in graph/tests/entity_cache.rs so you can test the entire path of loading derived entities. The tests in there right now use a MockStore, but this test should use the proper test_store::STORE etc. It would have to set up its own subgraph with a schema that uses a derived field, populate it with data and then test loading, probably with some edge cases, e.g., for an entity where the set of related entities is empty. Have a look at the tests in store/postgres/tests for some of the helpers we have to set up test subgraphs.

graph/src/data/schema.rs Outdated Show resolved Hide resolved
Copy link
Collaborator

@lutter lutter left a 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.

@gusinacio
Copy link
Contributor Author

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 @derivedFrom with single entity (I found within the code) and with array of entities.

I'll look through the document you sent and, if it is the case, try to fail gracefully until the follow-on PR.

@lutter
Copy link
Collaborator

lutter commented Mar 20, 2023

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?

@lutter
Copy link
Collaborator

lutter commented Mar 20, 2023

@flametuner can you rebase to latest master?

@azf20
Copy link
Contributor

azf20 commented Mar 20, 2023

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 graph-ts?

@gusinacio
Copy link
Contributor Author

@lutter I added some tests. I found a bug while testing and fixed it in writable.rs. I would like you to review again now that I'm 100% comfortable with the code. I tested 9 edge cases with both the query to the database and the query from async queue.

@gusinacio
Copy link
Contributor Author

@lutter is there anything blocking this PR? Please let me know so I can fix it.

@lutter
Copy link
Collaborator

lutter commented Mar 23, 2023

@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.

@lutter
Copy link
Collaborator

lutter commented Mar 24, 2023

@flametuner I think it needs a little bit of additional work - most of the CI checks are failing

@gusinacio
Copy link
Contributor Author

@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.

@lutter lutter merged commit bed5887 into graphprotocol:master Mar 29, 2023
6 checks passed
@lutter
Copy link
Collaborator

lutter commented Mar 29, 2023

@flametuner Thanks a ton for this PR. Great work!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Access derived fields in mappings
3 participants