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

fix: Allow grafts to add data sources #3989

Merged
merged 1 commit into from
Oct 3, 2022
Merged

Conversation

leoyvens
Copy link
Collaborator

Resolves #3960. This is done by adding a raw_yaml column to the subgraph_manifest table, and using it to map the manifest idx from the source to the destination deployment. For existing deployments this column is migrated in the instance manager on subgraph startup. This also changes a bit the order in which things are done in the instance manager, now the subgraph is first fetched from IPFS before being started in the store.

The data-source-revert integration test was modified to also test this.

Copy link
Member

@neysofu neysofu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, and nice small cleanups along the way! Just left two minor comments.

}
}

pub fn template_idx_and_name(&self) -> Result<Vec<(i32, String)>, Error> {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I understand we're using i32 to simplify comparing these values with query results, but it would be nice to postpone the conversion and create a type alias for this tuple.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could be but I'll be lazy and leave it for now

.load::<Tuple>(conn)?;

let mut count = 0;
for (block_range, src_manifest_idx, param, context, causality_region) in src_tuples {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suspect these N+1 queries may take longer than we'd like, but I don't have a better idea and N is most likely small for most subgraphs.

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.

The general approach looks good! Just some smaller detail comments on how we go about storing the raw yaml.

($($err:tt)*) => {
return Err(anyhow::anyhow!($($err)*).into());
};
}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why don't we just use the existing anyhow::bail! macro? If this is truly needed, maybe add a comment why.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It doesn't call .into(), yhea needs a comment.

graphql/tests/query.rs Show resolved Hide resolved
) -> Result<(), StoreError> {
use subgraph_manifest as sm;

update(sm::table.filter(sm::id.eq(site.id)))
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be better to also include .filter(sm::raw_yaml.ne(raw_yaml)) to avoid unnecessary updates in that table. Otherwise, we'd rewrite the entire table on each node start.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch, I've added a .filter(sm::raw_yaml.is_null()) clause.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good! The sideeffect is that we'll never update the raw_yaml once it's set, but that shouldn't be an issue

@leoyvens leoyvens force-pushed the leo/grafting-add-data-source branch 2 times, most recently from 2768f86 to 21e9548 Compare October 3, 2022 13:40
@leoyvens leoyvens force-pushed the leo/grafting-add-data-source branch from 21e9548 to cf6d023 Compare October 3, 2022 13:43
@leoyvens
Copy link
Collaborator Author

leoyvens commented Oct 3, 2022

Thanks for the reviews, @lutter I've addressed your comments.

@leoyvens leoyvens merged commit 3b3b458 into master Oct 3, 2022
@leoyvens leoyvens deleted the leo/grafting-add-data-source branch October 3, 2022 17:47
leoyvens added a commit that referenced this pull request Oct 4, 2022
leoyvens added a commit that referenced this pull request Oct 4, 2022
leoyvens added a commit that referenced this pull request Oct 4, 2022
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.

Adding data sources in graft not working
3 participants