# Payment

The <mark style="color:blue;">**`Payment`**</mark> resource will be pretty simple. This time, choose <mark style="color:red;">**no**</mark> to **CRUD entry points**.

```sh
nest g res domain/payments
```

This time, as we didn't create CRUD entry points, an entity was not created, so please create it in <mark style="color:purple;">entities</mark> -> <mark style="color:purple;">payment.entity</mark>. Then, define the attributes.

```typescript
id: number;
registryDates: RegistryDates;
```

Also associate the ORM decorators, and register it inside the <mark style="color:blue;">`TypeOrmModule`</mark>.

An order **may or may not** have a payment, and a payment **always** belongs to an order. So we can declare a **one-to-one** relationship, starting on the order's side.

```typescript
@OneToOne(() => Payment, (payment) => payment.order, { cascade: true })
payment: Payment;
```

{% hint style="info" %}
The <mark style="color:blue;">`cascade`</mark> option allows for saving both an order and its respective payment in a single operation.
{% endhint %}

We can now do the same on the payment's side.

```typescript
@OneToOne(() => Order, (order) => order.payment, {
  nullable: false,
  onDelete: 'CASCADE',
})
@JoinColumn()
order: Order;
```

{% hint style="info" %}
Some things to note:

* <mark style="color:blue;">`nullable: false`</mark> forces a payment to always be related to an order
* <mark style="color:blue;">`onDelete: 'CASCADE'`</mark> makes that an order deletion also deletes its payment
* <mark style="color:blue;">`@JoinColumn()`</mark> is necessary in a one-to-one relationship to indicate, at a database level, which side is the owner side. That is, which side has a reference to the other one. As a payment is dependent on an order, it is the better candidate.
  {% endhint %}

Let's finish by generating and running the migration <mark style="color:orange;">create-payment</mark>.

<mark style="color:green;">**Commit**</mark> - Creating payment entity and handling one to one relation