You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@@ -18,8 +16,6 @@ This project conforms to the specification laid out in the [jsonapi-server handl
18
16
* Postgres
19
17
* MySQL
20
18
* MariaDB
21
-
* SQLite
22
-
* Microsoft SQL Server
23
19
24
20
### Usage
25
21
@@ -30,6 +26,9 @@ jsonApi.define({
30
26
resource:"comments",
31
27
handlers:newRelationalDbStore({
32
28
dialect:"mysql",
29
+
dialectOptions: {
30
+
supportBigNumbers:true
31
+
},
33
32
host:"localhost",
34
33
port:3306,
35
34
database:"jsonapi", // If not provided, defaults to the name of the resource
@@ -64,6 +63,14 @@ When deploying schema changes, you'll need to correct your database schema - dat
64
63
65
64
When changing columns in a production database, a typical approach might be to create a new table that is a clone of the table in production, copy all data from the production table into the new table, run an ALTER-TABLE command on the new table to adjust the columns (this may take a while and will lock the table), then run a RENAME-TABLES to swap the production table out for the new one.
66
65
66
+
**Note:** When populating database tables, you can use the `force` config option to DROP and CREATE tables. This is helpful in development stage, when your data doesn't matter and you want your Tables schemas to change according to the DAOs without having to manually write migrations.
Relational databases don't differentiate between `undefined` and `null` values. `Joi` does differentiate between `undefined` and `null` values. Some `undefined` properties will pass validation, whilst `null` properties may not. For example, the default articles resource contains a `created` attribute of type `"date"` - this won't pass validation with a `null` value, so the Joi schema will need tweaking.
0 commit comments