Ist es in Ordnung, das Reset-Flag bei jeder Truffle-Kompilierung und -Migration zu verwenden, wenn der TestRPC-Client verwendet wird?

Ich habe gerade ziemlich viel Zeit damit verbracht, mir den Kopf zu kratzen, um herauszufinden, warum meine Truffle-Migration beim Versuch, sie auf dem TestRPC-Client bereitzustellen, nichts bewirkt hat. Es hieß immer nur "using network testrpc" ohne nachfolgende Statusmeldungen. Ich habe versucht, die Kompilierung mehrmals während der Debugging-Sitzung erneut auszuführen, und es gab keine Fehler.

Ich habe dann eine Migration mit dem Flag „--reset“ durchgeführt und festgestellt, dass eine neue Smart-Contract-Datei, die ich hinzugefügt habe, während der Migration nicht gefunden wurde („ist nicht definiert“. Ich arbeite noch daran, da der Code und der Vertrag vorhanden sind ).

Um in Zukunft Zeit zu sparen, schadet es immer, das Flag --reset bei einer Truffle-Kompilierung und -Migration einzubeziehen, zumindest wenn der TestRPC-Client verwendet wird?

Was sind die Nachteile der Verwendung des "--reset"-Flags in Zeit oder Gas, wenn eine Migration im Hauptnetz und in Zeit im Testnetz durchgeführt wird (vorausgesetzt, es gibt welche)?

Verursacht das „--reset“-Flag, dass Kompilierungen langsamer sind, ähnlich wie beim „Reinigen“ eines C++-Projekts, was dazu führt, dass alle Quelldateien erneut in Objektdateien kompiliert werden müssen? Löst es bei Migrationen die Notwendigkeit aus, den gesamten Smart-Contract-Code im Bereitstellungsnetzwerk „neu zu veröffentlichen“, anstatt nur die geänderten Smart-Contracts (d. h. nur die Differenz)?

Antworten (1)

Das --resetFlag erzwingt die erneute Ausführung aller Ihrer Migrationsskripts. Kompilieren, wenn sich einige der Verträge geändert haben. Sie müssen für die gesamte Migration erneut Benzin bezahlen. Für ganache/testrpc sollte es kein Problem sein, es ist nur eine zusätzliche Verzögerung. Aber für die Bereitstellung in einem öffentlichen Netzwerk: Mainnet, Rinkeby, Ropsten usw. kann es wirklich ärgerlich sein, auf winzige Änderungen warten zu müssen.

Die --allFlagge zwingt dazu, alle Ihre Verträge neu zu kompilieren. Auch wenn sie sich nicht geändert haben. Es ist mehr Zeit, alle Ihre Verträge zu kompilieren, und danach müssen alle Ihre Bereitstellungsskripts erneut ausgeführt werden.

Ich habe festgestellt, dass Truffle manchmal nicht bestätigt, dass ein Vertrag geändert wurde, und ihn nicht erneut kompiliert, die Bereitstellungsskripts nicht ausführt. Auch mit beiden Flaggen --allund --resetes wird nicht funktionieren. Wenn alles fehlschlägt, können Sie das build/Verzeichnis löschen. Dies erzwingt eine Neukompilierung aller Ihrer Verträge und die erneute Ausführung aller Ihrer Bereitstellungsskripts.

Danke. Ich denke, manche Dinge ändern sich nie. Das ist die gleiche Reihe von Prozeduren, jede zunehmend extremer, Sie müssen mit fast allen Sprachen mit einem Kompilierschritt zu tun haben, wenn die Dinge "einfach nicht richtig erscheinen".