ent/doc: grammar and typo fixes

Reviewed By: dlvhdr

Differential Revision: D17152480

fbshipit-source-id: dfd248625ba8be9bf3b5f922f29b476821fdf78e
This commit is contained in:
Ariel Mashraki
2019-09-02 02:22:50 -07:00
committed by Facebook Github Bot
parent 5c16c2fa64
commit 684d219a35
5 changed files with 42 additions and 32 deletions

View File

@@ -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.

View File

@@ -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
![er-linked-list](https://entgo.io/assets/er_linked_list.png)
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
![er-user-spouse](https://entgo.io/assets/er_user_spouse.png)
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
![er-following-followers](https://entgo.io/assets/er_following_followers.png)
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

View File

@@ -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

View File

@@ -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;

View File

@@ -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.