Subgraph update #60
Subgraph update #60
Conversation
…rCollective, and Donation
packages/subgraph/schema.graphql
Outdated
| @@ -95,11 +98,11 @@ type EventData @entity { | |||
| rewardPerContributor: BigInt! | |||
| contributors: [Steward!]! | |||
| nft: ProvableNFT! | |||
| claim: Claim | |||
| claim: Claim! @derivedFrom(field: "event") | |||
There was a problem hiding this comment.
@krisbitney I might miss a discussion / context here
but basically this now reads as:
instead of having many events to 1 claim, there is many claims to 1 event?
Is that right? I looked here and does seem to be the other way around:
There was a problem hiding this comment.
but if this is right, then approved! :)
There was a problem hiding this comment.
Oops! I thought it was a 1:1 relationship. I'll get this fixed.
There was a problem hiding this comment.
Is it correct to say the eventUri is unique for each event? If not, can you please advise how we would uniquely identify events?
Alternatively, if events cannot be distinguished with a unique identifier, is there an issue with aggregating the events for each claim so there is one event per claim?
There was a problem hiding this comment.
When you have a minute, please check the changes in my latest commit. It creates a m:1 relationship for EventData and Claim. It uses eventUri as the unique id for EventData.
| directPaymentPool.stewards = new Array<string>(); | ||
| directPaymentPool.save(); | ||
| directPaymentPool.projectId = projectID.toHexString(); |
There was a problem hiding this comment.
this is a string I believe, not hex
There was a problem hiding this comment.
It is of type Bytes in the event. Are you saying the Bytes represent a utf-8 string?
There was a problem hiding this comment.
This is fixed in #63
| const contributors = event.params.contributers; | ||
| const rewardPerContributor = event.params.rewardPerContributer; | ||
|
|
||
| const nftAddress = claimId.toHexString(); |
There was a problem hiding this comment.
this is incorrect. tokenId is the NFT id in the NFT contract. its not the nft contract address.
There was a problem hiding this comment.
mostly it should just be renamed to nftId
There was a problem hiding this comment.
resolved in #63
| donor: Donor! @derivedFrom(field: "collectives") | ||
| collective: Collective! @derivedFrom(field: "donors") |
There was a problem hiding this comment.
I dont think this will work. it has to be the other way around.
here it should just be donor: Donor! and collective: Collective!
in Collective and Donor there should be Donors: [DonorCollective!] @derivedFrom(field:"collective")
in Donor Collectives: [DonorCollective!] @derivedFrom(field:"donor")
There was a problem hiding this comment.
I wasn't aware that the derivedFrom relationship only works one way. Thanks!
There was a problem hiding this comment.
resolved in #63
There was a problem hiding this comment.
its not one way, but rather I dont think it can be derived from an array, how would it know which one?
| """NFT's minted to steward""" | ||
| nfts: [ProvableNFT!]! | ||
| """Collectives the steward is apart of""" | ||
| collectives: [StewardCollective!]! |
There was a problem hiding this comment.
same comment as on DonorCollective
There was a problem hiding this comment.
resolved in #63
| steward: Steward! @derivedFrom(field: "collectives") | ||
| collective: Collective! @derivedFrom(field: "stewards") |
There was a problem hiding this comment.
same comment as on donorcollective
There was a problem hiding this comment.
resolved in #63
| donors: [DonorCollective!]! | ||
| stewards: [StewardCollective!]! |
There was a problem hiding this comment.
see comment on collectivedonor/steward probably should have derivedfrom field
There was a problem hiding this comment.
resolved in #63
| rewardPerContributor: BigInt! | ||
| contributors: [Steward!]! | ||
| nft: ProvableNFT! | ||
| claim: Claim | ||
| claim: Claim! @derivedFrom(field: "events") |
There was a problem hiding this comment.
same comment as in CollectiveDonor, probably should be the other way around
There was a problem hiding this comment.
resolved in #63
I don't know what this is. Please provide more information. |
Every pool is a new contract, in order for subgraph to start capturing events for this pool it must be notified about this new contract. |
Awesome, thanks. This has been fixed in #63 |
This PR adds updates existing entities and adds new entities to the Subgraph:
These are breaking changes.
The updates will allow us to produce all of the data required by the UI design.
Closes #57
Questions
How do we calculate # of people supported by a donor? As in this part of the donor profile:
what is current pool? As in this part of the ViewCollective page:
which values are guaranteed to exist in a Collective's IPFS metadata?
#57 (comment)