Creating migrations files to create movies table and add movies check constraints. Updating API version number. Updating README.md adding 'SQL Migrations' section. Updating deployment file to make migrations before building API. Adding some .idea files into .gitignore.
Some checks failed
Deploy Greenlight API / deploy (push) Failing after 40s
Some checks failed
Deploy Greenlight API / deploy (push) Failing after 40s
This commit is contained in:
@@ -23,6 +23,10 @@ jobs:
|
|||||||
with:
|
with:
|
||||||
go-version: "1.23" # adapte selon ta version
|
go-version: "1.23" # adapte selon ta version
|
||||||
|
|
||||||
|
- name: Apply migrations
|
||||||
|
run: |
|
||||||
|
migrate -path=./migrations -database=$GREENLIGHT_DB_DSN up
|
||||||
|
|
||||||
- name: Build API
|
- name: Build API
|
||||||
run: |
|
run: |
|
||||||
go mod tidy
|
go mod tidy
|
||||||
|
|||||||
3
.gitignore
vendored
3
.gitignore
vendored
@@ -124,6 +124,9 @@ fabric.properties
|
|||||||
.idea/**/markdown-navigator.xml
|
.idea/**/markdown-navigator.xml
|
||||||
.idea/**/markdown-navigator-enh.xml
|
.idea/**/markdown-navigator-enh.xml
|
||||||
.idea/**/markdown-navigator/
|
.idea/**/markdown-navigator/
|
||||||
|
.idea/dataSources.xml
|
||||||
|
.idea/sqldialects.xml
|
||||||
|
.idea/sshConfigs.xml
|
||||||
|
|
||||||
# Cache file creation bug
|
# Cache file creation bug
|
||||||
# See https://youtrack.jetbrains.com/issue/JBR-2257
|
# See https://youtrack.jetbrains.com/issue/JBR-2257
|
||||||
|
|||||||
15
README.md
15
README.md
@@ -44,6 +44,21 @@ There are two comon approaches to doing this :
|
|||||||
|
|
||||||
From an HTTP semantics point of view, using headers to convey the API version is the 'purer' approach. But from a user-experience point of view, using a URL prefix is arguably better. It makes it possible for developers to see which version of the API is being used at a glance, and it also means that the API can still be explored using a regular web browser (which is harder if custom headers are required).
|
From an HTTP semantics point of view, using headers to convey the API version is the 'purer' approach. But from a user-experience point of view, using a URL prefix is arguably better. It makes it possible for developers to see which version of the API is being used at a glance, and it also means that the API can still be explored using a regular web browser (which is harder if custom headers are required).
|
||||||
|
|
||||||
|
## SQL Migrations
|
||||||
|
|
||||||
|
The first thing we need to do is generate a pair of _migration files_ using the **migrate create** command :
|
||||||
|
|
||||||
|
```bash
|
||||||
|
migrate create -seq -ext=.sql -dir=./migrations create_movies_table
|
||||||
|
```
|
||||||
|
|
||||||
|
In this command:
|
||||||
|
|
||||||
|
- The **-seq** flag indicates that we want to use sequential numbering like **0001, 0002, ...** for the migration files (instead of a Unix timestamp, which is the default).
|
||||||
|
- The **-ext** flag indicates that we want to give the migration files the extension **.sql**.
|
||||||
|
- The **-dir** flag indicates that we want to store the migration files in the **./migrations** directory (which will be created automatically if it doesn't already exist).
|
||||||
|
- The name **create_movies_table** is a descriptive label that we give the migration files to signify their contents.
|
||||||
|
|
||||||
## Additional Information
|
## Additional Information
|
||||||
|
|
||||||
### How different Go Types are encoded
|
### How different Go Types are encoded
|
||||||
|
|||||||
@@ -19,7 +19,7 @@ Declare a string containing the application version number.
|
|||||||
Later we'll generate this automatically at build time, but for now we'll just store the
|
Later we'll generate this automatically at build time, but for now we'll just store the
|
||||||
version number as a hard-coded global constant.
|
version number as a hard-coded global constant.
|
||||||
*/
|
*/
|
||||||
const version = "1.0.0"
|
const version = "0.0.1"
|
||||||
|
|
||||||
/*
|
/*
|
||||||
Define a config struct to hold all the configuration settings for our application.
|
Define a config struct to hold all the configuration settings for our application.
|
||||||
|
|||||||
1
migrations/000001_create_movies_table.down.sql
Normal file
1
migrations/000001_create_movies_table.down.sql
Normal file
@@ -0,0 +1 @@
|
|||||||
|
DROP TABLE IF EXISTS movies;
|
||||||
9
migrations/000001_create_movies_table.up.sql
Normal file
9
migrations/000001_create_movies_table.up.sql
Normal file
@@ -0,0 +1,9 @@
|
|||||||
|
CREATE TABLE IF NOT EXISTS movies (
|
||||||
|
id bigserial PRIMARY KEY,
|
||||||
|
created_at timestamp(0) with time zone NOT NULL DEFAULT NOW(),
|
||||||
|
title text NOT NULL,
|
||||||
|
year integer NOT NULL,
|
||||||
|
runtime integer NOT NULL,
|
||||||
|
genres text[] NOT NULL,
|
||||||
|
version integer NOT NULL DEFAULT 1
|
||||||
|
);
|
||||||
3
migrations/000002_add_movies_check_constraints.down.sql
Normal file
3
migrations/000002_add_movies_check_constraints.down.sql
Normal file
@@ -0,0 +1,3 @@
|
|||||||
|
ALTER TABLE movies DROP CONSTRAINT IF EXISTS movies_runtime_check;
|
||||||
|
ALTER TABLE movies DROP CONSTRAINT IF EXISTS movies_year_check;
|
||||||
|
ALTER TABLE movies DROP CONSTRAINT IF EXISTS genres_length_check;
|
||||||
5
migrations/000002_add_movies_check_constraints.up.sql
Normal file
5
migrations/000002_add_movies_check_constraints.up.sql
Normal file
@@ -0,0 +1,5 @@
|
|||||||
|
ALTER TABLE movies ADD CONSTRAINT movies_runtime_check CHECK (runtime >= 0);
|
||||||
|
|
||||||
|
ALTER TABLE movies ADD CONSTRAINT movies_year_check CHECK (year BETWEEN 1888 AND date_part('year', now()));
|
||||||
|
|
||||||
|
ALTER TABLE movies ADD CONSTRAINT genres_length_check CHECK (array_length(genres, 1) BETWEEN 1 AND 5);
|
||||||
Reference in New Issue
Block a user