Erstellen eines Subgraphen für HumanityDAO (Teil 1)

Wenn alles gut gelaufen ist, haben Sie einen Untergraphen erstellt!

Ändern wir die Codebasis des Untergraphen, die automatisch generiert wird, um sie an unsere Bedürfnisse anzupassen. Stellen Sie sich vor, wir möchten die Vertragsdaten so indizieren, dass wir später alle Vorschläge für eine bestimmte Adresse abfragen können. Die graphql-Abfrage lautet:

{
Antragsteller (zuerst: 10) {    
Adresse
vorschläge {
proposalData
}
} 
}

Der erste Schritt besteht darin, den Namen des Vertrags zu ändern, der von graph-cli automatisch verknüpft wird. Gehe zum abis Ordner und umbenennen contract.json zu HumanityGovernance.jsonErsetzen Sie dann in subgraph.yaml alle Vorkommen von Contract durch HumanityGovernance. Zu ändernde Tasten:

"Name", "source", "abis"

HumanityDAO hat seinen Code in mehrere Verträge aufgeteilt, und der HumanityGovernance-Vertrag behandelt leider nicht die vollständigen Daten, die wir benötigen. Daher müssen wir das Schema ändern, um die Daten für einen anderen Vertrag zu erfassen.

Fügen wir den zweiten Vertrag hinzu. Gehe zu subgraph.yaml und fügen Sie diesen Code unter dem Schlüssel dataSources hinzu:

- Art: Ethereum / Vertrag
name: TwitterHumanityApplicant
Netzwerk: Mainnet
Quelle:
Adresse: "0x9D661f7773Be14439b4223F5b516bC7Ef67b0369"
abi: TwitterHumanityApplicant
Kartierung:
Art: Ethereum / Veranstaltungen
apiVersion: 0.0.3
sprache: wasm / assemblyscript
Entitäten:
- Vorschlag
abis:
- Name: TwitterHumanityApplicant
Datei: ./abis/TwitterHumanityApplicant.json
eventHandlers:
- event: Apply (indizierte uint256, indizierte Adresse, Zeichenfolge)
Handler: handleApply
Datei: ./src/mapping.ts

Diesmal wird das ABI für den Vertrag nicht direkt heruntergeladen, aber wir können das leicht lösen, indem wir es aus dem Etherscan-Abschnitt „Contract ABI“ entnehmen. Erstellen Sie eine Datei mit dem Namen TwitterHumanityApplicant.json in der abis Ordner, und fügen Sie das ABI dort.

Fahren Sie fort, indem Sie die Hauptentitäten definieren, die für diesen Untergraphen verwendet werden sollen. Wechseln Sie zu subgraph.yaml, und ändern Sie in der ersten dataSource den Entitätsschlüssel so, dass er die folgenden Werte enthält:

- Antragsteller
- Vorschlag

Führen Sie in der zweiten dataSource dasselbe aus, jedoch mit dem folgenden Wert:

- Vorschlag

Gehe zu schema.graphql und füge dies an:

enum ProposalResult {
STEHT AUS
GENEHMIGT
ABGELEHNT
}Typ Proposer @entity {
Ich tat!
Adresse: Zeichenfolge!
Vorschläge: [Proposal!]! @derivedFrom (Feld: "Antragsteller")
}Geben Sie Proposal @entity {ein.
Ich tat!
proposalData: String!
Antragsteller: Antragsteller!
Ergebnis: ProposalResult!
countYesVotes: BigInt!
countNoVotes: BigInt!
}

Wir werden dies später genauer analysieren. Im Moment wissen, dass die Antragsteller Entität enthält alle Adressen, die jemals ein Twitter-Konto als Teil der Registrierung vorgeschlagen haben. Das Vorschlag Entität enthält Informationen über das Angebot selbst.

Aktualisieren Sie nun die Datei subgraph.yaml, um diese Änderung widerzuspiegeln, indem Sie den Entitätsschlüssel in beiden dataSources wie folgt ändern:

Entitäten:
- Antragsteller
- Vorschlag

Die eventHandler müssen ebenfalls aktualisiert werden.

Die erste dataSource ist:

eventHandlers:
- event: Propose (indizierte uint256, indizierte Adresse, indizierte Adresse, Bytes)
Handler: handlePropose

Der zweite wird sein:

eventHandlers:
- event: Apply (indizierte uint256, indizierte Adresse, Zeichenfolge)
Handler: handleApply

Jetzt nehmen wir einige Änderungen an der mapping.ts Datei innerhalb der src Mappe. Hier passiert die Magie! Wir müssen Graph Node jedes Mal mitteilen, was passieren soll, wenn ein Block verarbeitet wird. Ersetzen Sie den Inhalt durch diesen:

{Address, BigInt} aus "@ graphprotocol / graph-ts" importierenimportieren {
Als ProposeEvent vorschlagen,
HumanityGovernance,
} aus ‘../generated/HumanityGovernance/HumanityGovernance’
{Als ApplyEvent anwenden} aus ‘../generated/TwitterHumanityApplicant/TwitterHumanityApplicant’ importieren
{Proposer, Proposal} aus "../generated/schema" importierenconst proposalResultPending = "PENDING"Exportfunktion handlePropose (Ereignis: ProposeEvent): void {
let proposerId = event.transaction.hash.toHex () + ‘-’ + event.logIndex.toString ()
let proposer = new Proposer (proposerId)
proposer.address = ’’ // wir werden dieses Feld in handleApply füllen
proposer.save ()let humanityGovernance = getHumanityGovernanceInstance (event.address)let proposalId = event.params.proposalId.toHex ()
let proposal = new Proposal (proposalId)
proposal.proposalData = ‘’ // Wir füllen dieses Feld in handleApply aus
proposal.proposer = proposerId
proposal.result = proposalResultPending
proposal.countYesVotes = humanityGovernance.proposalFee ()
proposal.countNoVotes = BigInt.fromI32 (0)
proposal.save ()
}Exportfunktion handleApply (Ereignis: ApplyEvent): void {}Funktion getHumanityGovernanceInstance (Adresse: Adresse): HumanityGovernance {return HumanityGovernance.bind (Adresse)
}

Lassen Sie uns das analysieren. Zunächst definieren wir a handlePropose Handler, der bei jedem Auslösen eines Angebotsereignisses aufgerufen wird. Die Struktur dieser Veranstaltung ist wie folgt:

event Propose (Uint indizierte ProposalId, Adresse indizierter Antragsteller, Adresse indiziertes Ziel, Bytedaten);

Mit diesen Informationen müssen wir zwei Instanzen erstellen – eine für die Antragsteller und ein anderer für die Vorschlag.

Für den Antragsteller setzen wir die Adresse mit einem leeren Wert, da die an das Ereignis gesendete Adresse nicht mit der Ethereum-Adresse zusammenhängt, mit der die Transaktionen gestartet wurden. Es ist verwandt mit dem TwitterHumanityApplicant Vertrag, was wir nicht wollen. Später aktualisieren wir es mit der realen Adresse.

Für den Vorschlag, die Ergebnis wird initialisiert als STEHT AUS standardmäßig und countVotesYes wird mit einem Wert aus dem HumanityGovernance-Vertrag initialisiert. Es wird als öffentliche Variable beibehalten proposalFeeAus diesem Grund müssen wir den Vertrag mit der Veranstaltungsadresse binden. Durch die Bindung an eine Vertragsadresse und den Aufruf der Vertragsmethoden erhalten wir öffentliche Informationen aus dem Vertrag.

Nach diesen Änderungen müssen wir den Code neu generieren. Wir machen das mit Garn Codegen.

Als Nächstes erstellen wir den Untergraphen auf dem lokalen Graph-Knoten, erstellen ihn und stellen ihn bereit. Führen Sie dazu die folgenden Befehle aus:

Garn schaffen-lokal
Garn einsatzlokal

Nachdem Sie den zweiten Befehl ausgeführt haben, wird ein Link angezeigt, der Sie zu einer GraphQL-Instanz umleitet. Wenn Graph Node nach einer Weile mit der Indizierung des Untergraphen beginnt, können Sie die Antragsteller und ihre Vorschläge abfragen:

{
Antragsteller (zuerst: 10) { 
Ich würde
Adresse
vorschläge {
Ich würde
proposalData
}
} 
}

Dies zeigt die ersten 10 Entitäten.

In diesem Tutorial haben wir einen Graph-Node ausgeführt und mit ihm interagiert, indem wir unseren eigenen Subgraphen implementiert haben. Das nächste Mal werden wir detailliert beschreiben, wie dieser Untergraph zum Transformieren von Daten und Abfragen der Blockchain verwendet wird. Bleib dran!