docs: fix broken and outdated internal documentation links in Cosmos SDK docs (#25051)
Co-authored-by: Alex | Interchain Labs <alex@interchainlabs.io>
This commit is contained in:
MozirDmitriy
GitHub
parent
b7710772ef
commit
a86597e99c
@ -34,4 +34,4 @@ Check out the docs for the various parts of the Cosmos stack.
|
||||
|
||||
* [**GitHub Discussions**](https://github.com/orgs/cosmos/discussions) - Ask questions and discuss SDK development on GitHub.
|
||||
* [**Discord**](https://discord.gg/cosmosnetwork) - Chat with Cosmos developers on Discord.
|
||||
* [**Found an issue?**](https://github.com/cosmos/cosmos-sdk/edit/main/docs/docs/README.md) - Help us improve this page by suggesting edits on GitHub.
|
||||
* [**Found an issue?**](https://github.com/cosmos/cosmos-sdk/edit/main/docs/README.md) - Help us improve this page by suggesting edits on GitHub.
|
||||
|
||||
2
docs/docs/build/build.md
vendored
2
docs/docs/build/build.md
vendored
@ -5,7 +5,7 @@ sidebar_position: 0
|
||||
# Build
|
||||
|
||||
* [Building Apps](./building-apps/00-app-go.md) - The documentation in this section will guide you through the process of developing your dApp using the Cosmos SDK framework.
|
||||
* [Modules](./modules/README.md) - Information about the various modules available in the Cosmos SDK: Auth, Authz, Bank, Circuit, Consensus, Distribution, Epochs, Evidence, Feegrant, Governance, Group, Mint, NFT, Protocolpool, Slashing, Staking, Upgrade, Genutil.
|
||||
* [Modules](../../../x/README.md) - Information about the various modules available in the Cosmos SDK: Auth, Authz, Bank, Circuit, Consensus, Distribution, Epochs, Evidence, Feegrant, Governance, Group, Mint, NFT, Protocolpool, Slashing, Staking, Upgrade, Genutil.
|
||||
* [Migrations](./migrations/01-intro.md) - See what has been updated in each release the process of the transition between versions.
|
||||
* [Packages](./packages/README.md) - Explore a curated collection of pre-built modules and functionalities, streamlining the development process.
|
||||
* [Tooling](./tooling/README.md) - A suite of utilities designed to enhance the development workflow, optimizing the efficiency of Cosmos SDK-based projects.
|
||||
|
||||
@ -19,7 +19,7 @@ A Protobuf `Msg` service processes [messages](./02-messages-and-queries.md#messa
|
||||
|
||||
Each module should define a Protobuf `Msg` service, which will be responsible for processing requests (implementing `sdk.Msg`) and returning responses.
|
||||
|
||||
As further described in [ADR 031](../architecture/adr-031-msg-service.md), this approach has the advantage of clearly specifying return types and generating server and client code.
|
||||
As further described in [ADR 031](../../../architecture/adr-031-msg-service.md), this approach has the advantage of clearly specifying return types and generating server and client code.
|
||||
|
||||
Protobuf generates a `MsgServer` interface based on a definition of `Msg` service. It is the role of the module developer to implement this interface, by implementing the state transition logic that should happen upon receival of each `sdk.Msg`. As an example, here is the generated `MsgServer` interface for `x/bank`, which exposes two `sdk.Msg`s:
|
||||
|
||||
|
||||
2
docs/docs/build/migrations/01-intro.md
vendored
2
docs/docs/build/migrations/01-intro.md
vendored
@ -12,4 +12,4 @@ Additionally, the SDK includes in-place migrations for its core modules. These i
|
||||
|
||||
Migration from a version older than the last two major releases is not supported.
|
||||
|
||||
When migrating from a previous version, refer to the [`UPGRADING.md`](./02-upgrading.md) and the `CHANGELOG.md` of the version you are migrating to.
|
||||
When migrating from a previous version, refer to the [`UPGRADING.md`](../../../../UPGRADING.md) and the `CHANGELOG.md` of the version you are migrating to.
|
||||
|
||||
@ -33,7 +33,7 @@ An Event contains:
|
||||
To parse the attribute values as strings, make sure to add `'` (single quotes) around each attribute value.
|
||||
:::
|
||||
|
||||
_Typed Events_ are Protobuf-defined [messages](../../build/architecture/adr-032-typed-events.md) used by the Cosmos SDK
|
||||
_Typed Events_ are Protobuf-defined [messages](../../../architecture/adr-032-typed-events.md) used by the Cosmos SDK
|
||||
for emitting and querying Events. They are defined in a `event.proto` file, on a **per-module basis** and are read as `proto.Message`.
|
||||
_Legacy Events_ are defined on a **per-module basis** in the module's `/types/events.go` file.
|
||||
They are triggered from the module's Protobuf [`Msg` service](../../build/building-modules/03-msg-services.md)
|
||||
@ -57,7 +57,7 @@ The following examples show how to query Events using the Cosmos SDK.
|
||||
| `tx.height=23` | Query all transactions at height 23 |
|
||||
| `message.action='/cosmos.bank.v1beta1.Msg/Send'` | Query all transactions containing a x/bank `Send` [Service `Msg`](../../build/building-modules/03-msg-services.md). Note the `'`s around the value. |
|
||||
| `message.module='bank'` | Query all transactions containing messages from the x/bank module. Note the `'`s around the value. |
|
||||
| `create_validator.validator='cosmosval1...'` | x/staking-specific Event, see [x/staking SPEC](../../build/modules/staking/README.md). |
|
||||
| `create_validator.validator='cosmosval1...'` | x/staking-specific Event, see [x/staking SPEC](../../../../x/staking/README.md). |
|
||||
|
||||
## EventManager
|
||||
|
||||
|
||||
@ -32,7 +32,7 @@ This module is used in the Cosmos Hub.
|
||||
|
||||
## Concepts
|
||||
|
||||
**Note:** The auth module is different from the [authz module](../modules/authz/).
|
||||
**Note:** The auth module is different from the [authz module](../authz/).
|
||||
|
||||
The differences are:
|
||||
|
||||
|
||||
@ -35,7 +35,7 @@ The `table` struct does not:
|
||||
|
||||
The `table` struct is private, so that we only have custom tables built on top of it, that do satisfy these requirements.
|
||||
|
||||
`table` provides methods for exporting (using a [`PrefixScan` `Iterator`](03_iterator_pagination.md#iterator)) and importing genesis data. For the import to be successful, objects have to be aware of their primary key by implementing the [`PrimaryKeyed`](#primarykeyed) interface.
|
||||
`table` provides methods for exporting (using a [`PrefixScan` `Iterator`](#iterator)) and importing genesis data. For the import to be successful, objects have to be aware of their primary key by implementing the [`PrimaryKeyed`](#primarykeyed) interface.
|
||||
|
||||
### AutoUInt64Table
|
||||
|
||||
@ -72,7 +72,7 @@ Key parts, except the last part, follow these rules:
|
||||
|
||||
## Secondary Index
|
||||
|
||||
Secondary indexes can be used on `Indexable` [tables](01_table.md). Indeed, those tables implement the `Indexable` interface that provides a set of functions that can be called by indexes to register and interact with the tables, like callback functions that are called on entries creation, update or deletion to create, update or remove corresponding entries in the table secondary indexes.
|
||||
Secondary indexes can be used on `Indexable` [tables](#table). Indeed, those tables implement the `Indexable` interface that provides a set of functions that can be called by indexes to register and interact with the tables, like callback functions that are called on entries creation, update or deletion to create, update or remove corresponding entries in the table secondary indexes.
|
||||
|
||||
```go reference
|
||||
https://github.com/cosmos/cosmos-sdk/tree/release/v0.50.x/x/group/internal/orm/types.go#L88-L93
|
||||
@ -96,7 +96,7 @@ https://github.com/cosmos/cosmos-sdk/tree/release/v0.50.x/x/group/internal/orm/i
|
||||
https://github.com/cosmos/cosmos-sdk/tree/release/v0.50.x/x/group/internal/orm/indexer.go#L15-L19
|
||||
```
|
||||
|
||||
The currently used implementation of an `indexer`, `Indexer`, relies on an `IndexerFunc` that should be provided when instantiating the index. Based on the source object, this function returns one or multiple index keys as `[]interface{}`. Such secondary index keys should be bytes, string or `uint64` in order to be handled properly by the [key codec](01_table.md#key-codec) which defines specific encoding for those types.
|
||||
The currently used implementation of an `indexer`, `Indexer`, relies on an `IndexerFunc` that should be provided when instantiating the index. Based on the source object, this function returns one or multiple index keys as `[]interface{}`. Such secondary index keys should be bytes, string or `uint64` in order to be handled properly by the [key codec](#key-codec) which defines specific encoding for those types.
|
||||
In the index prefix store, the keys are built based on the source object's `RowID` and its secondary index key(s) using the key codec and the values are set as empty bytes.
|
||||
|
||||
### UniqueIndex
|
||||
@ -105,7 +105,7 @@ As opposed to `MultiKeyIndex`, `UniqueIndex` is an index where duplicate keys ar
|
||||
|
||||
## Iterator and Pagination
|
||||
|
||||
Both [tables](01_table.md) and [secondary indexes](02_secondary_index.md) support iterating over a domain of keys, through `PrefixScan` or `ReversePrefixScan`, as well pagination.
|
||||
Both [tables](#table) and [secondary indexes](#secondary-index) support iterating over a domain of keys, through `PrefixScan` or `ReversePrefixScan`, as well pagination.
|
||||
|
||||
### Iterator
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user