mirror of
https://github.com/ent/ent.git
synced 2026-05-24 09:31:56 +03:00
ent/doc: grammar and typo fixes
Reviewed By: dlvhdr Differential Revision: D17152480 fbshipit-source-id: dfd248625ba8be9bf3b5f922f29b476821fdf78e
This commit is contained in:
committed by
Facebook Github Bot
parent
5c16c2fa64
commit
684d219a35
@@ -6,11 +6,12 @@ title: Introduction
|
||||
## Quick Summary
|
||||
|
||||
Schema describes the definition of one entity type in the graph, like `User` or `Group`,
|
||||
and can contains the following configuration:
|
||||
and can contain the following configurations:
|
||||
- Entity fields (or properties), like: name or age of a `User`.
|
||||
- Entity edges (or relations), like: `User`'s groups, or `User`'s friends.
|
||||
- Database specific options, like: indexes or unique indexes.
|
||||
|
||||
<br/>
|
||||
Here's an example of a schema:
|
||||
|
||||
```go
|
||||
@@ -63,5 +64,5 @@ $ entc init User Group
|
||||
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 will help you to get started,
|
||||
and can be found in the [edges section](schema-edges.md).
|
||||
There are many examples in this website that can help you get started
|
||||
in the [Edges](schema-edges.md) section.
|
||||
|
||||
@@ -75,14 +75,14 @@ func (Pet) Edges() []ent.Edge {
|
||||
}
|
||||
```
|
||||
|
||||
As you can see, a `User` entity can have many pets, but a `Pet` entity can have only one owner.
|
||||
As you can see, a `User` entity can **have many** pets, but a `Pet` entity can **have only one** owner.
|
||||
In relationship definition, the `pets` edge is a *O2M* (one-to-many) relationship, and the `owner` edge
|
||||
is a *M2O* (many-to-one) relationship.
|
||||
|
||||
The `User` schema **owns** the `pets/owner` relationship because it uses `edge.To`, and the `Pet` schema
|
||||
just have a back-reference to it, declared using `edge.From` with the `Ref` method.
|
||||
just has a back-reference to it, declared using `edge.From` with the `Ref` method.
|
||||
|
||||
The `Ref` method describes which edge of the `User` schema we're referencing to, because, there can be multiple
|
||||
The `Ref` method describes which edge of the `User` schema we're referencing because there can be multiple
|
||||
references from one schema to other.
|
||||
|
||||
The cardinality of the edge/relationship can be controlled using the `Unique` method, and it's explained
|
||||
@@ -151,7 +151,7 @@ func (User) Edges() []ent.Edge {
|
||||
}
|
||||
```
|
||||
|
||||
As you can see, a Group entity can have many users, and a User entity can have have many groups.
|
||||
As you can see, a Group entity can **have many** users, and a User entity can have **have many** groups.
|
||||
In relationship definition, the `users` edge is a *M2M* (many-to-many) relationship, and the `groups`
|
||||
edge is also a *M2M* (many-to-many) relationship.
|
||||
|
||||
@@ -159,15 +159,13 @@ edge is also a *M2M* (many-to-many) relationship.
|
||||
|
||||
`edge.To` and `edge.From` are the 2 builders for creating edges/relations.
|
||||
|
||||
A schema that defines an edge using the `edge.To` builder is owning the relation,
|
||||
unlike using the `edge.From` builder that gives only a reference for the relation (with different name).
|
||||
A schema that defines an edge using the `edge.To` builder owns the relation,
|
||||
unlike using the `edge.From` builder that gives only a back-reference for the relation (with a different name).
|
||||
|
||||
Let's go over a few examples, that show how to define different relation types using edges.
|
||||
Let's go over a few examples that show how to define different relation types using edges.
|
||||
|
||||
## Relationship
|
||||
|
||||
The following examples:
|
||||
|
||||
- [O2O Two Types](#o2o-two-types)
|
||||
- [O2O Same Type](#o2o-same-type)
|
||||
- [O2O Bidirectional](#o2o-bidirectional)
|
||||
@@ -184,7 +182,7 @@ The following examples:
|
||||
In this example, a user **has only one** credit-card, and a card **has only one** owner.
|
||||
|
||||
The `User` schema defines an `edge.To` card named `card`, and the `Card` schema
|
||||
defines a reference to this edge using `edge.From` named `owner`.
|
||||
defines a back-reference to this edge using `edge.From` named `owner`.
|
||||
|
||||
|
||||
`ent/schema/user.go`
|
||||
@@ -261,7 +259,7 @@ The full example exists in [GitHub](https://github.com/facebookincubator/ent/tre
|
||||

|
||||
|
||||
In this linked-list example, we have a **recursive relation** named `next`/`prev`. Each node in the list can
|
||||
have only of `next`. If a node A points (using `next`) to a node B, B can get its pointer using `prev`.
|
||||
**have only one** `next` node. If a node A points (using `next`) to node B, B can get its pointer using `prev` (the back-reference edge).
|
||||
|
||||
`ent/schema/node.go`
|
||||
```go
|
||||
@@ -356,10 +354,10 @@ The full example exists in [GitHub](https://github.com/facebookincubator/ent/tre
|
||||
|
||||

|
||||
|
||||
In this user-spouse example, we have a **symmetric O2O relation** named `spouse`. Each user can have only one spouse.
|
||||
In this user-spouse example, we have a **symmetric O2O relation** named `spouse`. Each user can **have only one** spouse.
|
||||
If user A sets its spouse (using `spouse`) to B, B can get its spouse using the `spouse` edge.
|
||||
|
||||
Note that, there's no owner/inverse terms in cases of bidirectional edges.
|
||||
Note that there are no owner/inverse terms in cases of bidirectional edges.
|
||||
|
||||
`ent/schema/user.go`
|
||||
```go
|
||||
@@ -432,9 +430,9 @@ The full example exists in [GitHub](https://github.com/facebookincubator/ent/tre
|
||||
|
||||
In this user-pets example, we have a O2M relation between user and its pets.
|
||||
Each user **has many** pets, and a pet **has one** owner.
|
||||
If user A adds a pet B using the `pets` edge, B can get its owner using the `owner` edge.
|
||||
If user A adds a pet B using the `pets` edge, B can get its owner using the `owner` edge (the back-reference edge).
|
||||
|
||||
Note that, this relation is also a M2O (many-to-one) from the point of view of the `Pet` schema.
|
||||
Note that this relation is also a M2O (many-to-one) from the point of view of the `Pet` schema.
|
||||
|
||||
`ent/schema/user.go`
|
||||
```go
|
||||
@@ -712,7 +710,7 @@ The full example exists in [GitHub](https://github.com/facebookincubator/ent/tre
|
||||
|
||||

|
||||
|
||||
In this following-followers example, we have a M2M relation between users to its followers. Each user
|
||||
In this following-followers example, we have a M2M relation between users to their followers. Each user
|
||||
can follow **many** users, and can have **many** followers.
|
||||
|
||||
`ent/schema/user.go`
|
||||
@@ -809,7 +807,7 @@ The full example exists in [GitHub](https://github.com/facebookincubator/ent/tre
|
||||
In this user-friends example, we have a **symmetric M2M relation** named `friends`.
|
||||
Each user can **have many** friends. If user A becomes a friend of B, B is also a friend of A.
|
||||
|
||||
Note that, there's no owner/inverse terms in cases of bidirectional edges.
|
||||
Note that there are no owner/inverse terms in cases of bidirectional edges.
|
||||
|
||||
`ent/schema/user.go`
|
||||
```go
|
||||
|
||||
@@ -46,12 +46,13 @@ All fields are required by default, and can be set to optional using the `Option
|
||||
|
||||
The following types are currently supported by the framework:
|
||||
|
||||
- All Go numeric types. Like, `int`, `uint8`, `float64`, etc.
|
||||
- All Go numeric types. Like `int`, `uint8`, `float64`, etc.
|
||||
- `bool`
|
||||
- `string`
|
||||
- `time.Time`
|
||||
- `[]byte` (only support by SQL dialects).
|
||||
- `[]byte` (only supported by SQL dialects).
|
||||
|
||||
<br/>
|
||||
```go
|
||||
package schema
|
||||
|
||||
@@ -106,10 +107,10 @@ func (User) Fields() []ent.Field {
|
||||
## Validators
|
||||
|
||||
A field validator is a function from type `func(T) error` that is defined in the schema
|
||||
using the `Validate` method, and applied on the given field value before creating or updating
|
||||
using the `Validate` method, and applied on the field value before creating or updating
|
||||
the entity.
|
||||
|
||||
The supported types for field validators are `string` and all numeric types.
|
||||
The supported types of field validators are `string` and all numeric types.
|
||||
|
||||
```go
|
||||
package schema
|
||||
@@ -145,9 +146,9 @@ func (Group) Fields() []ent.Field {
|
||||
}
|
||||
```
|
||||
|
||||
## Builtin Validators
|
||||
## Built-in Validators
|
||||
|
||||
The framework provides a few builtin validators for each type:
|
||||
The framework provides a few built-in validators for each type:
|
||||
|
||||
- Numeric types:
|
||||
- `Positive()`
|
||||
@@ -181,8 +182,9 @@ func (User) Fields() []ent.Field {
|
||||
```
|
||||
|
||||
## Nillable
|
||||
Sometime, you want to be able to distinguish between the zero value of fields
|
||||
and `nil`. For example, if the database column contains `0` or `NULL`. The `Nillable` option exists exactly for this.
|
||||
Sometimes you want to be able to distinguish between the zero value of fields
|
||||
and `nil`; for example if the database column contains `0` or `NULL`.
|
||||
The `Nillable` option exists exactly for this.
|
||||
|
||||
If you have an `Optional` field of type `T`, setting it to `Nillable` will generate
|
||||
a struct field with type `*T`. Hence, if the database returns `NULL` for this field,
|
||||
@@ -213,7 +215,7 @@ package ent
|
||||
type User struct {
|
||||
RequiredName string `json:"required_name,omitempty"`
|
||||
OptionalName string `json:"optional_name,omitempty"`
|
||||
NillableName string `json:"nillable_name,omitempty"`
|
||||
NillableName *string `json:"nillable_name,omitempty"`
|
||||
}
|
||||
```
|
||||
|
||||
@@ -236,7 +238,7 @@ func (User) Fields() []ent.Field {
|
||||
|
||||
## Uniqueness
|
||||
Fields can be defined as unique using the `Unique` method.
|
||||
Note that, unique fields cannot have default values.
|
||||
Note that unique fields cannot have default values.
|
||||
|
||||
```go
|
||||
// Fields of the user.
|
||||
@@ -258,7 +260,7 @@ Read more about this in the [Indexes](schema-indexes.md) section.
|
||||
## Struct Tags
|
||||
|
||||
Custom struct tags can be added to the generated entities using the `StructTag`
|
||||
method. Note that, if this option was not provided, or provided and did not
|
||||
method. Note that if this option was not provided, or provided and did not
|
||||
contain the `json` tag, the default `json` tag will be added with the field name.
|
||||
|
||||
```go
|
||||
|
||||
@@ -1,4 +1,9 @@
|
||||
/* your custom css */
|
||||
/*
|
||||
Copyright 2019-present Facebook Inc. All rights reserved.
|
||||
This source code is licensed under the Apache 2.0 license found
|
||||
in the LICENSE file in the root directory of this source tree.
|
||||
*/
|
||||
|
||||
@font-face {
|
||||
font-family: 'Calibre Medium';
|
||||
font-style: normal;
|
||||
|
||||
@@ -1,3 +1,7 @@
|
||||
// Copyright 2019-present Facebook Inc. All rights reserved.
|
||||
// This source code is licensed under the Apache 2.0 license found
|
||||
// in the LICENSE file in the root directory of this source tree.
|
||||
|
||||
/* eslint-disable */
|
||||
window.addEventListener('load', function() {
|
||||
// add an id tag for images based on their alt attribute.
|
||||
|
||||
Reference in New Issue
Block a user