However, if you never need to be able to migrate down, you can leave out the down block. Migrations should include both up and down blocks, with the down block reversing the change made by up. This migration has an up block which adds an artist table with an integer primary key named id, and a varchar or text column (depending on the database) named name that doesn’t accept NULL values. migration do up do create_table( :artists) do primary_key :id String :name, null: false end end down do drop_table( :artists) Here is a fairly basic Sequel migration: Sequel. See the schema modification guide for details on the schema modification methods you can use. Migrations in Sequel use a DSL via the Sequel.migration method, and inside the DSL, use the Sequel::Database schema modification methods such as create_table and alter_table. Sequel tracks which migrations you have already run, so to apply migrations you generally need to run Sequel’s migrator with bin/sequel -m: sequel -m path/to/migrations postgres://host/database Even if you aren’t dealing with other developers, you generally have to make the schema changes in 3 places (development, testing, and production), and it’s probably easier to use the migrations system to apply the schema changes than it is to keep track of the changes manually and execute them manually at the appropriate time. However, if you are dealing with other developers, you’ll have to send them all of the changes you are making. You can always just create the necessary database structure manually using Sequel’s schema modification methods or another database tool. Migrations are optional, you don’t have to use them. They make it easier to coordinate with other developers and make sure that all developers are using the same database schema. Migrations make it easy to alter your database’s schema in a systematic manner. This guide is based on /migrations.html Overview ¶ ↑
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |