mirror of
https://github.com/ent/ent.git
synced 2026-03-05 19:35:23 +03:00
doc/md: fix some broken links caused by trailing slash (#3990)
This commit is contained in:
@@ -26,7 +26,7 @@ is to have an `ent` directory under the root directory of the project.
|
||||
|
||||
## Generate Assets
|
||||
|
||||
After adding a few [fields](schema-fields.mdx) and [edges](schema-edges), you want to generate
|
||||
After adding a few [fields](schema-fields.mdx) and [edges](schema-edges.mdx), you want to generate
|
||||
the assets for working with your entities. Run `ent generate` from the root directory of the project,
|
||||
or use `go generate`:
|
||||
|
||||
|
||||
@@ -14,7 +14,7 @@ migrations and integrate them into your regular schema migrations workflow.
|
||||
|
||||
### Migration Types
|
||||
|
||||
Ent currently supports two types of migrations, [versioned migration](versioned-migrations.mdx) and [declarative migration](migrate)
|
||||
Ent currently supports two types of migrations, [versioned migration](versioned-migrations.mdx) and [declarative migration](migrate.md)
|
||||
(also known as automatic migration). Data migrations can be executed in both types of migrations.
|
||||
|
||||
## Versioned Migrations
|
||||
@@ -267,7 +267,7 @@ until the data migration file achieves the desired result.
|
||||
|
||||
## Automatic Migrations
|
||||
|
||||
In the declarative workflow, data migrations are implemented using Diff or Apply [Hooks](migrate#atlas-diff-and-apply-hooks).
|
||||
In the declarative workflow, data migrations are implemented using Diff or Apply [Hooks](migrate.md#atlas-diff-and-apply-hooks).
|
||||
This is because, unlike the versioned option, migrations of this type do not hold a name or a version when they are applied.
|
||||
Therefore, when a data is written using hooks, the type of the `schema.Change` must be checked before its
|
||||
execution to ensure the data migration was not applied more than once.
|
||||
|
||||
@@ -47,7 +47,7 @@ func (User) Fields() []ent.Field {
|
||||
## Custom Table Schema
|
||||
|
||||
Using the [Atlas](https://atlasgo.io) migration engine, an Ent schema can be defined and managed across multiple
|
||||
database schemas. Check out the [multi-schema doc](multischema-migrations) for more information.
|
||||
database schemas. Check out the [multi-schema doc](multischema-migrations.mdx) for more information.
|
||||
|
||||
## Foreign Keys Configuration
|
||||
|
||||
|
||||
@@ -70,4 +70,4 @@ If you are used to the definition of relations over edges, that's fine.
|
||||
The modeling is the same. You can model with `ent` whatever you can model
|
||||
with other traditional ORMs.
|
||||
There are many examples in this website that can help you get started
|
||||
in the [Edges](schema-edges) section.
|
||||
in the [Edges](schema-edges.mdx) section.
|
||||
|
||||
@@ -150,7 +150,7 @@ The full example exists in [GitHub](https://github.com/ent/ent/tree/master/examp
|
||||
|
||||
## Index On Edge Fields
|
||||
|
||||
Currently `Edges` columns are always added after `Fields` columns. However, some indexes require these columns to come first in order to achieve specific optimizations. You can work around this problem by making use of [Edge Fields](schema-edges#edge-field).
|
||||
Currently `Edges` columns are always added after `Fields` columns. However, some indexes require these columns to come first in order to achieve specific optimizations. You can work around this problem by making use of [Edge Fields](schema-edges.mdx#edge-field).
|
||||
|
||||
```go
|
||||
// Card holds the schema definition for the Card entity.
|
||||
|
||||
@@ -12,7 +12,7 @@ Ent provides, such as:
|
||||
1. Generating a GraphQL schema for nodes and edges defined in an Ent schema.
|
||||
2. Auto-generated `Query` and `Mutation` resolvers and provide seamless integration with the [Relay framework](https://relay.dev/).
|
||||
3. Filtering, pagination (including nested) and compliant support with the [Relay Cursor Connections Spec](https://relay.dev/graphql/connections.htm).
|
||||
4. Efficient [field collection](tutorial-todo-gql-field-collection) to overcome the N+1 problem without requiring data
|
||||
4. Efficient [field collection](tutorial-todo-gql-field-collection.md) to overcome the N+1 problem without requiring data
|
||||
loaders.
|
||||
5. [Transactional mutations](tutorial-todo-gql-tx-mutation.md) to ensure consistency in case of failures.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user