Codegen and config validation fixes (#474)

.github/workflows/build.yml

@@ -2,17 +2,17 @@ name: Build
 on:
   push:
     branches:
-      - "**"
+      - '**'
     tags:
       - '*.*.*'
     paths:
-      - "src/**"
-      - "Dockerfile"
-      - "Dockerfile.slim"
-      - "pyproject.toml"
-      - "poetry.lock"
-      - "Makefile"
-      - ".github/workflows/build.yml"
+      - 'src/**'
+      - 'Dockerfile'
+      - 'Dockerfile.slim'
+      - 'pyproject.toml'
+      - 'poetry.lock'
+      - 'Makefile'
+      - '.github/workflows/build.yml'
 
 jobs:
   build:

.github/workflows/cookiecutter.yml

@@ -2,8 +2,8 @@ name: Test cookiecutter
 on:
   push:
     paths:
-      - "cookiecutter/**"
-      - ".github/workflows/cookiecutter.yml"
+      - 'cookiecutter/**'
+      - '.github/workflows/cookiecutter.yml'
 
 jobs:
   test:
@@ -18,12 +18,12 @@ jobs:
       - name: Set up Python
         uses: actions/setup-python@v2
         with:
-          python-version: "3.10.x"
+          python-version: '3.10.x'
 
       - name: Set up Poetry
         uses: snok/install-poetry@v1
         with:
-          version: "1.2.0"
+          version: '1.2.0'
 
       - name: Set up cache
         uses: actions/cache@v2

.github/workflows/docs.yml

@@ -3,13 +3,13 @@ concurrency: ci-${{ github.ref }}
 on:
   push:
     tags:
-      - "*.*.*"
+      - '*.*.*'
     branches:
       - master
     paths:
       - 'docs/**'
       - 'scripts/**'
-      - ".github/workflows/docs.yml"
+      - '.github/workflows/docs.yml'
 
 jobs:
   docs:
@@ -24,12 +24,12 @@ jobs:
     - name: Set up Python
       uses: actions/setup-python@v2
       with:
-        python-version: "3.10.x"
+        python-version: '3.10.x'
 
     - name: Set up Poetry
       uses: snok/install-poetry@v1
       with:
-        version: "1.2.0"
+        version: '1.2.0'
 
     - name: Set up cache
       uses: actions/cache@v2

.github/workflows/release.yml

@@ -2,7 +2,7 @@ name: Release
 on:
   push:
     tags:
-      - "*.*.*"
+      - '*.*.*'
 
 jobs:
   release:
@@ -69,12 +69,12 @@ jobs:
       - name: Set up Python
         uses: actions/setup-python@v2
         with:
-          python-version: "3.10.x"
+          python-version: '3.10.x'
 
       - name: Set up Poetry
         uses: snok/install-poetry@v1
         with:
-          version: "1.2.0"
+          version: '1.2.0'
 
       - name: Install project
         run: make install

.github/workflows/test.yml

@@ -2,12 +2,12 @@ name: Test
 on:
   push:
     paths:
-      - "src/**"
-      - "tests/**"
-      - "pyproject.toml"
-      - "poetry.lock"
-      - "Makefile"
-      - ".github/workflows/test.yml"
+      - 'src/**'
+      - 'tests/**'
+      - 'pyproject.toml'
+      - 'poetry.lock'
+      - 'Makefile'
+      - '.github/workflows/test.yml'
 
 jobs:
   test:
@@ -33,12 +33,12 @@ jobs:
       - name: Set up Python
         uses: actions/setup-python@v2
         with:
-          python-version: "3.10.x"
+          python-version: '3.10.x'
 
       - name: Set up Poetry
         uses: snok/install-poetry@v1
         with:
-          version: "1.2.0"
+          version: '1.2.0'
 
       - name: Set up cache
         uses: actions/cache@v2

CHANGELOG.md

@@ -7,12 +7,16 @@ and this project adheres to [Semantic Versioning].
 
 ## [Unreleased]
 
-### Fixed
+### Added
 
-- tzkt: Quote field `gbp` added.
+- config: Added `alias` field to operation pattern items.
+- tzkt: Added quote field `gbp`.
 
 ### Fixed
 
+- config: Require aliases for multiple operations with the same entrypoint.
+- http: Raise `InvalidRequestError` on 204 No Content responses.
+- tzkt: Verify API version on datasource initialization.
 - tzkt: Remove deprecated block field `priority`.
 
 ## [6.1.1] - 2022-09-01
@@ -788,4 +792,4 @@ This release contains no changes except for the version number.
 [3.0.3]: https://github.com/dipdup-net/dipdup-py/compare/3.0.2...3.0.3
 [3.0.2]: https://github.com/dipdup-net/dipdup-py/compare/3.0.1...3.0.2
 [3.0.1]: https://github.com/dipdup-net/dipdup-py/compare/3.0.0...3.0.1
-[3.0.0]: https://github.com/Author/Repository/releases/tag/3.0.0
+[3.0.0]: https://github.com/dipdup-net/dipdup-py/releases/tag/3.0.0

docs/book.css

@@ -1,3 +1,7 @@
+body {
+    font-size: 1.55rem  /* was 1.6rem */
+}
+
 h2, h3 {
     margin-top: 1.5em;  /* was 2.5em */
 }
@@ -6,3 +10,9 @@ pre > code {
     padding: 1.5rem;  /* was 1rem */
     font-size: 0.825em;  /* was 0.875em; */
 }
+
+.float-img {
+    float: right;
+    width: 35%;
+    padding: 1.5em;
+}

docs/config/indexes/README.md

@@ -2,7 +2,7 @@
 
 _Index_ — is a basic DipDup entity connecting the inventory and specifying data handling rules.
 
-Each index has a unique string identifier acting as a key under `indexes` config section:
+Each index has a unique string identifier acting as a key under the `indexes` config section:
 
 ```yaml
 indexes:
@@ -11,16 +11,20 @@ indexes:
     datasource: tzkt_mainnet
 ```
 
-There can be various index kinds; currently, two possible options are supported for the `kind` field:
+There can be various index kinds; currently, the following options are supported for the `kind` field:
 
-* `operation`
 * `big_map`
+* `head`
+* `operation`
+* `token_transfer`
+
+There's also a special `template` kind, which is used to generate new indexes from a template during startup.
 
 All the indexes have to specify the `datasource` field, an alias of an existing entry under the [datasources](../datasources.md) section.
 
 ## Indexing scope
 
-One can optionally specify block levels DipDup has to start and stop indexing at, e.g., there's a new version of the contract, and it will be more efficient to stop handling the old one.
+One can optionally specify block levels DipDup has to start and stop indexing at, e.g., there's a new version of the contract, and there's no need to track the old one anymore.
 
 ```yaml
 indexes:

docs/config/indexes/operation.md

@@ -1,10 +1,15 @@
+<div class="float-img">
+  <img src="../../assets/operation-bcd.png" alt="Operation group in BCD explorer">
+  <img src="../../assets/operation-config.png" alt="`operation` index config">
+</div>
+
 # operation
 
-Operation index allows you to query only those operations related to your DApp and do pattern matching on its content (internal calls chain). It is the closest thing to fully-fledged event logs.
+Operation index allows you to query only operations related to your dapp and match them with handlers by content. A single contract call consists of implicit operation and, optionally, internal operations. For each of them, you can specify a handler that will be called when operation group. As a result, you get something like an event log for your dapp.
 
 ## Filters
 
-DipDup supports filtering operations by `kind`, `source`, `destination` (if applicable), and `originated_contract` (if applicable).
+DipDup supports filtering operations by `source`, `destination` (if applicable), and `originated_contract` (if applicable).
 
 DipDup fetches only _applied_ operations.
 
@@ -24,41 +29,41 @@ In this example, DipDup will fetch all the operations where any of source and de
 
 ### types
 
-By default, DipDup works only with transactions, but you can explicitly list operation types you want to subscribe to (currently `transaction` and `origination` types are supported):
+By default, DipDup works only with transactions, but you can explicitly list operation types you want to subscribe to (currently `transaction`, `origination` and `migration` types are supported):
 
 ```yaml
 indexes:
   my_index:
     kind: operation
     datasource: tzkt
     contracts:
-      - contract1
+      - some_contract
     types:
       - transaction
       - origination
 ```
 
-Note that in the case of originations, DipDup will query operations where either source or originated contract address is equal to _contract1._
+Note that in the case of originations, DipDup will query operations where either source or originated contract address is equal to _some\_contract_.
 
 ## Handlers
 
 Each operation handler contains two required fields:
 
-* `callback` —  name of the _async_ function with a particular signature; DipDup will try to load it from the module with the same name `<package_name>.handlers.<callback>`
-* `pattern` — a non-empty list of items that have to be matched
+* `callback` —  name of the _async_ function with a particular signature; DipDup will create it on init and in the module with the same name `<package_name>.handlers.<callback>`.
+* `pattern` — a non-empty list of items that need to be matched.
 
 ```yaml
 indexes:
   my_index:
     kind: operation
     datasource: tzkt
     contracts:
-      - contract1
+      - some_contract
     handlers:
       - callback: on_call
         pattern:
-          - destination: contract1
-            entrypoint: call        
+          - destination: some_contract
+            entrypoint: transfer
 ```
 
 You can think of operation pattern as a regular expression on a sequence of operations (both external and internal) with global flag enabled (can be multiple matches) and where various operation parameters (type, source, destination, entrypoint, originated contract) are used for matching.
@@ -67,7 +72,7 @@ You can think of operation pattern as a regular expression on a sequence of oper
 
 Here are the supported filters for matching operations (all optional):
 
-* `type` — (either _transaction_ or _origination_) usually inferred from the existence of other fields
+* `type` — _transaction_ or _origination_; usually inferred from the existence of other fields
 * `destination` — invoked contract alias (from the [inventory](../contracts.md))
 * `entrypoint` — invoked entrypoint name
 * `source` — operation sender alias (from the [inventory](../contracts.md))
@@ -80,17 +85,16 @@ It's unnecessary to match the entire operation content; you can skip external/in
 
 ```yaml
 pattern:
-  - destination: contract_1
-    entrypoint: call_1
-  - destination: contract_2
-    entrypoint: internal_call_2
-  - source: contract_1
+  # Implicit transaction
+  - destination: some_contract
+    entrypoint: mint
+
+  # Internal transactions below
+  - destination: another_contract
+    entrypoint: transfer
+
+  - source: some_contract
     type: transaction
-  - source: contract_2
-    type: origination
-    similar_to: contract_3
-    strict: true
-    optional: true
 ```
 
 You will get slightly different callback argument types depending on whether you specify _destination+entrypoint_ for transactions and _originated\_contract_ for originations. Namely, in the first case, DipDup will generate the dataclass for a particular entrypoint/storage, and in the second case not (meaning you will have to handle untyped parameters/storage updates).