%PDF- %PDF-
Direktori : /home/opti/workflow/node_modules/sequelize-cli/docs/ |
Current File : /home/opti/workflow/node_modules/sequelize-cli/docs/README.md |
## Options The manuals will show all the flags and options which are available for the respective tasks. If you find yourself in a situation where you always define certain flags in order to make the CLI compliant to your project, you can move those definitions also into a file called `.sequelizerc`. The file will get `require`d if available and can therefore be either a JSON file or a Node.JS script that exports a hash. You can also use the `--options-path` option to declare a path to another configuration file. ### Example for a Node.JS script ```js var path = require('path') module.exports = { 'config': path.resolve('config', 'database.json'), 'migrations-path': path.resolve('db', 'migrate') } ``` This will configure the CLI to always treat `config/database.json` as config file and `db/migrate` as the directory for migrations. ### Configuration file By default the CLI will try to use the file `config/config.js` and `config/config.json`. You can modify that path either via the `--config` flag or via the option mentioned earlier. Here is how a configuration file might look like (this is the one that `sequelize init` generates): ```json { "development": { "username": "root", "password": null, "database": "database_development", "host": "127.0.0.1", "dialect": "mysql" }, "test": { "username": "root", "password": null, "database": "database_test", "host": "127.0.0.1", "dialect": "mysql" }, "production": { "username": "root", "password": null, "database": "database_production", "host": "127.0.0.1", "dialect": "mysql" } } ``` The properties can also be combined to a `url`: ```json { "development": { "url": "mysql://root:password@mysql_host.com/database_name", "dialect": "mysql" } } ``` In case of a JS file it obviously needs to `module.exports` the object. Optionally, it's possible to put all the configuration to the `url` option. The format is explained in the section below. ### Configuration Connection String As an alternative to the `--config` option with configuration files defining your database, you can use the `--url` option to pass in a connection string. For example: `sequelize db:migrate --url 'mysql://root:password@mysql_host.com/database_name'` ### Configuration Connection Environment Variable Another possibility is to store the URL in an environment variable and to tell the CLI to lookup a certain variable during runtime. Let's assume you have an environment variable called `DB_CONNECTION_STRING` which stores the value `mysql://root:password@mysql_host.com/database_name`. In order to make the CLI use it, you have to use declare it in your config file: ```json { "production": { "use_env_variable": "DB_CONNECTION_STRING" } } ``` With v2.0.0 of the CLI you can also just directly access the environment variables inside the `config/config.js`: ```js module.exports = { "production": { "hostname": process.env.DB_HOSTNAME } } ``` ### Configuration for connecting over SSL Ensure ssl is specified in both `dialectOptions` and in the base config. ``` { "production": { "use_env_variable":"DB_CONNECTION_STRING", "dialect":"postgres", "ssl": true, "dialectOptions": { "ssl": true } } } ``` ### Storage There are three types of storage that you can use: `sequelize`, `json`, and `none`. - `sequelize` : stores migrations and seeds in a table on the sequelize database - `json` : stores migrations and seeds on a json file - `none` : does not store any migration/seed #### Migration By default the CLI will create a table in your database called `SequelizeMeta` containing an entry for each executed migration. To change this behavior, there are three options you can add to the configuration file. Using `migrationStorage`, you can choose the type of storage to be used for migrations. If you choose `json`, you can specify the path of the file using `migrationStoragePath` or the CLI will write to the file `sequelize-meta.json`. If you want to keep the information in the database, using `sequelize`, but want to use a different table, you can change the table name using `migrationStorageTableName`. ```js { "development": { "username": "root", "password": null, "database": "database_development", "host": "127.0.0.1", "dialect": "mysql", // Use a different storage type. Default: sequelize "migrationStorage": "json", // Use a different file name. Default: sequelize-meta.json "migrationStoragePath": "sequelizeMeta.json", // Use a different table name. Default: SequelizeMeta "migrationStorageTableName": "sequelize_meta", // Use a different schema (Postgres-only). Default: undefined "migrationStorageTableSchema": "sequelize_schema" } } ``` NOTE: The `none` storage is not recommended as a migration storage. If you decide to use it, be aware of the implications of having no record of what migrations did or didn't run. #### Seed By default the CLI will not save any seed that is executed. If you choose to change this behavior (!), you can use `seederStorage` in the configuration file to change the storage type. If you choose `json`, you can specify the path of the file using `seederStoragePath` or the CLI will write to the file `sequelize-data.json`. If you want to keep the information in the database, using `sequelize`, you can specify the table name using `seederStorageTableName`, or it will default to `SequelizeData`. ```js { "development": { "username": "root", "password": null, "database": "database_development", "host": "127.0.0.1", "dialect": "mysql", // Use a different storage. Default: none "seederStorage": "json", // Use a different file name. Default: sequelize-data.json "seederStoragePath": "sequelizeData.json", // Use a different table name. Default: SequelizeData "seederStorageTableName": "sequelize_data" } } ``` ### Dialect specific options In order to pass options to the underlying database connectors, you can add the property `dialectOptions` to your configuration like this: ```js var fs = require('fs'); module.exports = { development: { dialect: 'mysql', dialectOptions: { ssl: { ca: fs.readFileSync(__dirname + '/mysql-ca.crt') } } } }; ``` ### Schema migration Sequelize CLI continue to use schema from `v2` and fully compatible with `v2`. If you are still using old schema from pre `v2`, use `v2` to upgrade to current schema with `db:migrate:old_schema` #### Timestamps Since v2.8.0 the CLI supports a adding timestamps to the schema for saving the executed migrations. You can opt-in for timestamps by running the following command: ```bash $ sequelize db:migrate:schema:timestamps:add ``` ### The migration schema The CLI uses [umzug](https://github.com/sequelize/umzug) and its migration schema. This means a migration has to look like this: ```js "use strict"; module.exports = { up: function(queryInterface, Sequelize, done) { done(); }, down: function(queryInterface) { return new Promise(function (resolve, reject) { resolve(); }); } }; ``` Please note that you can either return a Promise or call the third argument of the function once your asynchronous logic was executed. If you pass something to the callback function (the `done` function) it will be treated as erroneous execution. Additional note: If you need to access the sequelize instance, you can easily do that via `queryInterface.sequelize`. For example `queryInterface.sequelize.query('CREATE TABLE mytable();')`.