asana2flowdock 1.0.0 → 1.1.0

data/vendor/bundle/ruby/1.9.1/gems/sequel-4.15.0/doc/dataset_filtering.rdoc

@@ -1,191 +0,0 @@
-= Dataset Filtering 
-
-Sequel is very flexibile when it comes to filtering records. You can specify your conditions as a custom string, as a string with parameters, as a hash of values to compare against, or as ruby code that Sequel translates into SQL expressions.
-
-== Filtering using a custom filter string
-
-If you wish to write your SQL by hand, you can just supply it to the dataset's #where method:
-
-  items.where('x < 10').sql
-  #=> "SELECT * FROM items WHERE x < 10"
-
-In order to prevent SQL injection, you can replace literal values with question marks and supply the values as additional arguments:
-
-  items.where('category = ?', 'ruby').sql
-  #=> "SELECT * FROM items WHERE category = 'ruby'"
-
-You can also use placeholders with :placeholder and a hash of placeholder values:
-
-  items.where('category = :category', :category=>'ruby').sql
-  #=> "SELECT * FROM items WHERE category = 'ruby'"
-
-=== Specifying SQL functions
-
-Sequel also allows you to specify functions by using the Sequel.function method:
-
-  items.literal(Sequel.function(:avg, :price)) #=> "avg(price)"
-
-If you are specifying a filter/selection/order, you can use a virtual row block:
-
-  items.select{avg(price)}
-
-You can also use the {core_extensions extension}[rdoc-ref:doc/core_extensions.rdoc] and the +sql_function+ method:
-
-  :avg.sql_function(:price)
-
-== Filtering using a hash
-
-If you just need to compare records against values, you can supply a hash:
-
-  items.where(:category => 'ruby').sql
-  #=> "SELECT * FROM items WHERE (category = 'ruby')"
-
-Sequel can check for null values:
-
-  items.where(:category => nil).sql
-  #=> "SELECT * FROM items WHERE (category IS NULL)"
-
-Or compare two columns:
-
-  items.where(:x => :some_table__y).sql
-  #=> "SELECT * FROM items WHERE (x = some_table.y)"
-
-And also compare against multiple values:
-
-  items.where(:category => ['ruby', 'perl']).sql
-  #=> "SELECT * FROM items WHERE (category IN ('ruby', 'perl'))"
-
-Ranges (both inclusive and exclusive) can also be used:
-
-  items.where(:price => 100..200).sql
-  #=> "SELECT * FROM items WHERE (price >= 100 AND price <= 200)"
-
-  items.where(:price => 100...200).sql
-  #=> "SELECT * FROM items WHERE (price >= 100 AND price < 200)"
-
-== Filtering using an array
-
-If you need to select multiple items from a dataset, you can supply an array:
-
-	item_array = [1, 38, 47, 99]
-	items.where(:id => item_array).sql
-	#=> "SELECT * FROM items WHERE (id IN (1, 38, 47, 99))"
-
-== Filtering using expressions
-
-You can pass a block to where, which is evaluated in a special context:
-
-  items.where{price * 2 < 50}.sql
-  #=> "SELECT * FROM items WHERE ((price * 2) < 50) 
-
-This works for the standard inequality and arithmetic operators:
-
-  items.where{price + 100 < 200}.sql
-  #=> "SELECT * FROM items WHERE ((price + 100) < 200) 
-
-  items.where{price - 100 > 200}.sql
-  #=> "SELECT * FROM items WHERE ((price - 100) > 200) 
-
-  items.where{price * 100 <= 200}.sql
-  #=> "SELECT * FROM items WHERE ((price * 100) <= 200) 
-
-  items.where{price / 100 >= 200}.sql
-  #=> "SELECT * FROM items WHERE ((price / 100) >= 200) 
-
-You use the overloaded bitwise and (&) and or (|) operators to combine expressions:
-
-  items.where{(price + 100 < 200) & (price * 100 <= 200)}.sql
-  #=> "SELECT * FROM items WHERE (((price + 100) < 200) AND ((price * 100) <= 200)) 
-
-  items.where{(price - 100 > 200) | (price / 100 >= 200)}.sql
-  #=> "SELECT * FROM items WHERE (((price - 100) > 200) OR ((price / 100) >= 200)) 
-
-To filter by equality, you use the standard hash, which can be combined with other expressions using Sequel.& and Sequel.|:
-
-  items.where{Sequel.&({:category => 'ruby'}, (price + 100 < 200))}.sql
-  #=> "SELECT * FROM items WHERE ((category = 'ruby') AND ((price + 100) < 200))"
-
-This works with other hash values, such as arrays and ranges:
-
-  items.where{Sequel.|({:category => ['ruby', 'other']}, (:price - 100 > 200))}.sql
-  #=> "SELECT * FROM items WHERE ((category IN ('ruby', 'other')) OR ((price - 100) <= 200))"
-
-  items.where{Sequel.&({:price => (100..200)}, :active)}.sql
-  #=> "SELECT * FROM items WHERE ((price >= 100 AND price <= 200) AND active)"
-
-=== Negating conditions
-
-You can use the exclude method to exclude conditions:
-
-  items.exclude(:category => 'ruby').sql
-  #=> "SELECT * FROM items WHERE (category != 'ruby')"
-
-  items.exclude(:active).sql
-  #=> "SELECT * FROM items WHERE NOT active"
-
-  items.exclude{price / 100 >= 200}.sql
-  #=> "SELECT * FROM items WHERE ((price / 100) < 200) 
-
-=== Comparing against column references
-
-You can also compare against other columns:
-
-  items.where{credit > debit}.sql
-  #=> "SELECT * FROM items WHERE (credit > debit)
-
-Or against SQL functions:
-
-  items.where{price - 100 < max(price)}.sql
-  #=> "SELECT * FROM items WHERE ((price - 100) < max(price))"
-
-== String search functions
-
-You can search SQL strings in a case sensitive manner using the Sequel.like method:
-
-  items.where(Sequel.like(:name, 'Acme%')).sql
-  #=> "SELECT * FROM items WHERE (name LIKE 'Acme%' ESCAPE '\')"
-
-You can search SQL strings in a case insensitive manner using the Sequel.ilike method:
-
-  items.where(Sequel.ilike(:name, 'Acme%')).sql
-  #=> "SELECT * FROM items WHERE (name ILIKE 'Acme%' ESCAPE '\')"
-
-You can specify a Regexp as a like argument, but this will probably only work
-on PostgreSQL and MySQL:
-
-  items.where(Sequel.like(:name, /Acme.*/)).sql
-  #=> "SELECT * FROM items WHERE (name ~ 'Acme.*')"
-
-Like can also take more than one argument:
-
-  items.where(Sequel.like(:name, 'Acme%', /Beta.*/)).sql
-  #=> "SELECT * FROM items WHERE ((name LIKE 'Acme%' ESCAPE '\') OR (name ~ 'Beta.*'))"
-
-== String concatenation
-
-You can concatenate SQL strings using Sequel.join: 
-
-  items.where(Sequel.join([:name, :comment]).like('%acme%')).sql
-  #=> "SELECT * FROM items WHERE ((name || comment) LIKE 'Acme%' ESCAPE '\')"
-
-Sequel.join also takes a join argument:
-
-  items.filter(Sequel.join([:name, :comment], ' ').like('%acme%')).sql
-  #=> "SELECT * FROM items WHERE ((name || ' ' || comment) LIKE 'Acme%' ESCAPE '\')"
-
-== Filtering using sub-queries
-
-One of the best features of Sequel is the ability to use datasets as sub-queries. Sub-queries can be very useful for filtering records, and many times provide a simpler alternative to table joins. Sub-queries can be used in all forms of filters:
-
-  refs = consumer_refs.where(:logged_in).select(:consumer_id)
-  consumers.where(:id => refs).sql
-  #=> "SELECT * FROM consumers WHERE (id IN (SELECT consumer_id FROM consumer_refs WHERE logged_in))"
-
-Note that if you are checking for the inclusion of a single column in a subselect, the subselect should only select a single column.
-
-== Using OR instead of AND
-
-By default, if you chain calls to +where+, the conditions get ANDed together.  If you want to use an OR for a condition, you can use the +or+ method:
-
-  items.where(:name=>'Food').or(:vendor=>1).sql
-  #=> "SELECT * FROM items WHERE ((name = 'Food') OR (vendor = 1))"

data/vendor/bundle/ruby/1.9.1/gems/sequel-4.15.0/doc/extensions.rdoc

@@ -1,84 +0,0 @@
-= Sequel Extensions
-
-Sequel has an official extension system, for adding global, Database, and Dataset extensions.
-
-== Global Extensions
-
-Global extensions can add or modify the behavior of any part of Sequel.  Technically, they are not limited to affecting Sequel, as they can also modify code outside of Sequel (e.g. the blank extension).  However, extensions that modify things outside of Sequel generally do so only for backwards compatibility.
-
-Global extensions are loaded via <tt>Sequel.extension</tt>:
-
-  Sequel.extension :named_timezones
-
-What this does is require the relevent extension from <tt>sequel/extensions/named_timezones</tt> somewhere in the ruby path.  Actually, that is all that does.  Global extensions are just a simpler, consistent way to require code that modifies Sequel.
-
-== Database Extensions
-
-Database extensions should add or modify the behavior of a single <tt>Sequel::Database</tt> instance.  They are loaded via <tt>Sequel::Database#extension</tt>:
-
-  DB.extension :server_block
-
-The first thing that this does is load the relevent extension globally.  However, Database extensions should be structured in a way that loading the relevent extension globally just adds a module with the related behavior, it doesn't modify any other state.  After loading the extension globally, it modifies the related <tt>Sequel::Database</tt> object to modify it's behavior, usually by extending it with a module.
-
-If you want a Database extension loaded into all future Database instances, you can use <tt>Sequel::Database.extension</tt>:
-
-  Sequel::Database.extension :server_block
-
-All future <tt>Sequel::Database</tt> instances created afterward will then automatically have the server_block extension loaded.
-
-== Dataset Extensions
-
-Dataset extensions should add or modify the behavior of a single <tt>Sequel::Dataset</tt> instance.  They are loaded via <tt>Sequel::Dataset#extension</tt> or <tt>Sequel::Dataset#extension!</tt>.  <tt>Sequel::Dataset#extension</tt> returns a modifies copy of the dataset that includes the extension (similar to how most dataset query methods work):
-
-  ds = DB[:a].extension(:columns_introspection)
-
-<tt>Sequel::Dataset#extension!</tt> modifies a dataset to include the extension (similar to how dataset mutation methods work):
-  
-  ds = DB[:a]
-  ds.extension!(:columns_introspection)
-
-It is recommended you only use <tt>Sequel::Dataset#extension!</tt> if you have good reasons to.
-
-The first thing loading a Dataset extension does is load the relevent extension globally.  Similar to Database extensions, loading a Dataset extension globally should not affect state other than maybe adding a module.  After loading the extension globally, it modifies the related <tt>Sequel::Dataset</tt> instance to modify its behavior.
-
-If you want to load an extension into all future datasets for a given <tt>Sequel::Database</tt> instance, you can also load it as a Database extension:
-
-  DB.extension :columns_introspection
-
-Likewise, if you want to load an extension into all future datasets for all future databases, you can load it via <tt>Sequel::Database.extension</tt>:
-
-  Sequel::Database.extension :columns_introspection
-  
-== Creating Global Extensions
-
-If you want to create a global extension, you just need to store your code so that you can require it via <tt>sequel/extensions/extension_name</tt>.  Then users can load it via:
-
-  Sequel.extension :extension_name
-
-It is recommended you only create a global extension if what you want to do would not work as a Database or Dataset extension.
-
-== Creating Database Extensions
-
-Creating Database extensions is similar to global extensions in terms of creating the file.  However, somewhere in the file, you need to call <tt>Sequel::Database.register_extension</tt>.  Usually you would call this with the module that will be added to the related <tt>Sequel::Database</tt> instance when the extension is loaded.  For example, the server_block extension uses something like:
-
-  Sequel::Database.register_extension(:server_block, Sequel::ServerBlock)
-
-The first argument is the name of the extension as a symbol, and the second is the module.
-
-In some cases, just extending the <tt>Sequel::Database</tt> instance with a module is not sufficient.  So <tt>Sequel::Database.register_extension</tt> also accepts a proc instead of a second argument.  This proc is called with the <tt>Sequel::Database</tt> instance, and can then run any related code:
-
-  Sequel::Database.register_extension(:arbitrary_servers){|db| db.pool.extend(Sequel::ArbitraryServers)}
-
-== Creating Dataset Extensions
-
-Creating Dataset extensions is very similar to creating Database extensions, but instead of calling <tt>Sequel::Database.register_extension</tt>, you call <tt>Sequel::Dataset.register_extension</tt>.  In general, you would call this with the module that will be added to the related <tt>Sequel::Dataset</tt> instance when the extension is loaded.  For example, the columns_introspection extension uses something like:
-
-  Sequel::Dataset.register_extension(:columns_introspection, Sequel::ColumnsIntrospection)
-
-The first argument is the name of the extension as a symbol, and the second is the module.  When you call the <tt>Sequel::Dataset.register_extension</tt> method with a module, it in turn calls <tt>Sequel::Database.register_extension</tt> and adds a Database extension that loads this Dataset extension into all future Datasets created from the Database.
-
-You can also call <tt>Sequel::Dataset.register_extension</tt> with a proc:
-
-  Sequel::Dataset.register_extension(:extension_name){|ds| }
-
-Note that if you use a proc, a corresponding Database extension will not be created automatically (you can still call <tt>Sequel::Database.register_extension</tt> manually in this case).

data/vendor/bundle/ruby/1.9.1/gems/sequel-4.15.0/doc/mass_assignment.rdoc

@@ -1,55 +0,0 @@
-= Sequel::Model Mass Assignment
-
-Most Model methods that take a hash of attribute keys and values, including <tt>Model.new</tt>, <tt>Model.create</tt>, <tt>Model#set</tt> and <tt>Model#update</tt> are subject to Sequel's mass assignment rules.
-When you pass a hash to these methods, each key has an <tt>=</tt> appended to it (the setter method), and if the setter method exists and access to it is not restricted, Sequel will call the setter method with the hash value.
-By default, there are two types of setter methods that are restricted.  
-The first is methods like <tt>typecast_on_assignment=</tt> and <tt>==</tt>, which don't affect columns.
-These methods cannot be enabled for mass assignment.
-The second is primary key setters.
-To enable use of primary key setters, you need to call +unrestrict_primary_key+ for that model:
-
-  Post.unrestrict_primary_key
-
-Since mass assignment by default allows modification of all column values except for primary key columns, it can be a security risk in some cases.
-Sequel has multiple ways of securing mass assignment.
-The first way is using +set_allowed_columns+:
-
-  Post.set_allowed_columns :title, :body, :category
-
-This explicitly sets which methods are allowed (<tt>title=</tt>, <tt>body=</tt>, and <tt>category=</tt>), all other methods will not be allowed.
-This method is useful in simple applications where the same columns are allowed in all cases, but not appropriate when different columns are allowed in different scenarios (e.g. admin access vs. user access).
-To handle cases where different columns are allowed in different cases, you can use +set_only+ or +update_only+:
-
-  # user case
-  post.set_only(params[:post], :title, :body)
-  # admin case
-  post.set_only(params[:post], :title, :body, :deleted)
-
-In this case, only the <tt>title=</tt> and <tt>body=</tt> methods will be allowed in the mass assignment in the user case, and only <tt>title=</tt>, <tt>body=</tt>, and <tt>deleted=</tt> will be allowed for mass assignment in the admin case.
-
-By default, if an invalid setter method call is attempted, Sequel raises a <tt>Sequel::Error</tt> exception.  You can have Sequel silently ignore invalid calls by doing:
-
-  # Global default
-  Sequel::Model.strict_param_setting = false
-  # Class level
-  Post.strict_param_setting = false
-  # Instance level
-  post.strict_param_setting = false
-
-In addition to +set_only+ and +update_only+, Sequel also has +set_fields+ and +update_fields+ methods, and these may be a better mass assignment choice for most users.
-These methods take two arguments, the attributes hash as the first argument, and a single array of valid field names as the second argument:
-
-  post.set_fields(params[:post], [:title, :body])
-
-+set_fields+ and +update_fields+ differ in implementation from +set_only+ and +update_only+.
-With +set_only+ and +update_only+, the hash is iterated over and it checks each method call attempt to see if it is valid.
-With +set_fields+ and +update_fields+, the array is iterated over, and it just looks up the value in the hash and calls the appropriate setter method.
-
-+set_fields+ and +update_fields+ are designed for the case where you are expecting specific fields in the input, and want to ignore the other fields.
-They work great for things like HTML forms where the form fields are static.
-+set_only+ and +update_only+ are designed for cases where you are not sure what fields are going to be present in the input, but still want to make sure only certain setter methods can be called.
-They work great for flexible APIs.
-
-+set_fields+ and +update_fields+ take an optional argument hash, and currently handles the :missing option.  With <tt>:missing=>:skip</tt>, +set_fields+ and +update_fields+ will just skip missing entries in the hash, allowing them to be used in flexible APIs.  With <tt>:missing=>:raise</tt>, +set_fields+ and +update_fields+ will raise an error if one of the entries in the hash is missing, instead of just assigning the value to nil or whatever the hash's default value is.  That allows stricter checks, similar to the :strict_param_checking setting for the default mass assignment methods.  You can use the <tt>Model.default_set_fields_options=</tt> method to set the default options to use for +set_fields+ and +update_fields+ on a global or per-model basis.
-
-In all of the mass assignment cases, methods starting with +set+ will set the attributes without saving the object, while methods starting with +update+ will set the attributes and then save the changes to the object.

data/vendor/bundle/ruby/1.9.1/gems/sequel-4.15.0/doc/migration.rdoc

@@ -1,611 +0,0 @@
-= Migrations
-
-This guide is based on http://guides.rubyonrails.org/migrations.html
-
-== Overview
-
-Migrations make it easy to alter your database's schema in a systematic manner.
-They make it easier to coordinate with other developers and make sure that
-all developers are using the same database schema.
-
-Migrations are optional, you don't have to use them.  You can always just
-create the necessary database structure manually using Sequel's schema
-modification methods or another database tool.  However, if you are dealing
-with other developers, you'll have to send them all of the changes you are
-making.  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.
-
-Sequel tracks which migrations you have already run, so to apply migrations
-you generally need to run Sequel's migrator with <tt>bin/sequel -m</tt>:
-
-  sequel -m path/to/migrations postgres://host/database
-
-Migrations in Sequel use a very simple DSL via the <tt>Sequel.migration</tt>
-method, and inside the DSL, use the <tt>Sequel::Database</tt> schema
-modification methods such as +create_table+ and +alter_table+.
-See the {schema modification guide}[rdoc-ref:doc/schema_modification.rdoc]
-for details on the schema modification methods you can use.
-
-== A Basic Migration
-
-Here is a fairly basic Sequel migration:
-
-  Sequel.migration do
-    up do
-      create_table(:artists) do
-        primary_key :id
-        String :name, :null=>false
-      end
-    end
-
-    down do
-      drop_table(:artists)
-    end
-  end
-
-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.
-Migrations should include both up and +down+ blocks, with the +down+ block reversing
-the change made by up.  However, if you never need to be able to migrate down
-(i.e. you are one of the people that doesn't make mistakes), you can leave out
-the +down+ block.  In this case, the +down+ block just reverses the changes made by up,
-dropping the table.
-
-You can simplify the migration given above by using a reversible migration with a +change+
-block:
-
-  Sequel.migration do
-    change do
-      create_table(:artists) do
-        primary_key :id
-        String :name, :null=>false
-      end
-    end
-  end
-
-The +change+ block acts exactly like an +up+ block.  The only difference is that
-it will attempt to create a +down+ block for you, assuming that it knows how to
-reverse the given migration.  The +change+ block can usually correctly reverse
-the following methods:
-
-* +create_table+
-* +add_column+
-* +add_index+
-* +rename_column+
-* +rename_table+
-* +alter_table+ (supporting the following methods in the +alter_table+ block):
-  * +add_column+
-  * +add_constraint+
-  * +add_foreign_key+ (with a symbol, not an array)
-  * +add_primary_key+ (with a symbol, not an array)
-  * +add_index+
-  * +add_full_text_index+
-  * +add_spatial_index+
-  * +rename_column+
-
-If you use any other methods, you should create your own +down+ block.
-
-In normal usage, when Sequel's migrator runs, it runs the +up+ blocks for all
-migrations that have not yet been applied.  However, you can use the <tt>-M</tt>
-switch to specify the version to which to migrate, and if it is lower than the
-current version, Sequel will run the +down+ block on the appropriate migrations.
-
-You are not limited to creating tables inside a migration, you can alter existing tables
-as well as modify data.  Let's say your artist database originally only included artists
-from Sacramento, CA, USA, but now you want to branch out and include artists in any city:
-
-  Sequel.migration do
-    up do
-      add_column :artists, :location, String
-      from(:artists).update(:location=>'Sacramento')
-    end
-
-    down do
-      drop_column :artists, :location
-    end
-  end
-
-This migration adds a +location+ column to the +artists+ table, and sets the +location+ column
-to <tt>'Sacramento'</tt> for all existing artists.  It doesn't use a default on the column,
-because future artists should not be assumed to come from Sacramento.  In the +down+ block, it
-just drops the +location+ column from the +artists+ table, reversing the actions of the up
-block.
-
-Note that when updating the +artists+ table in the update, a plain dataset is used, <tt>from(:artists)</tt>.
-This looks a little weird, but you need to be aware that inside an up or +down+ block in a migration,
-self always refers to the <tt>Sequel::Database</tt> object that the migration is being applied to.
-Since <tt>Database#from</tt> creates datasets, using <tt>from(:artists)</tt> inside the +up+ block creates
-a dataset on the database representing all columns in the +artists+ table, and updates it to set the
-+location+ column to <tt>'Sacramento'</tt>.  You should avoid referencing the <tt>Sequel::Database</tt>
-object directly in your migration, and always use self to reference it, otherwise you may run into problems.
-
-It is possible to use model classes inside migrations, as long as they are loaded into the ruby interpreter,
-but it's a bad habit as changes to your model classes can then break old migrations, and this breakage is
-often not caught until much later, such as when a new developer joins the team and wants to run all migrations
-to create their development database.
-
-== The +migration+ extension
-
-The migration code is not technically part of the core of Sequel.  It's not loaded by default as it
-is only useful in specific cases.  It is one of the extensions that ship with Sequel, which receive the same
-level of support as Sequel's core.
-
-If you want to play with Sequel's migration tools without using the <tt>bin/sequel</tt> tool, you
-need to load the migration extension manually:
-
-  Sequel.extension :migration
-
-== Schema methods
-
-Migrations themselves do not contain any schema modification methods, but they make it easy to call
-any of the <tt>Sequel::Database</tt> modification methods, of which there are many.  The main
-ones are +create_table+ and +alter_table+, but Sequel also comes with numerous other schema
-modification methods, most of which are shortcuts for +alter_table+ (all of these methods are
-described in more detail in the {schema modification guide}[rdoc-ref:doc/schema_modification.rdoc]):
-
-* add_column
-* add_index
-* create_view
-* drop_column
-* drop_index
-* drop_table
-* drop_view
-* rename_table
-* rename_column
-* set_column_default
-* set_column_type
-
-These methods handle the vast majority of cross database schema modification SQL.  If you
-need to drop down to SQL to execute some database specific code, you can use the +run+
-method:
-
-  Sequel.migration do
-    up{run 'CREATE TRIGGER ...'}
-    down{run 'DROP TRIGGER ...'}
-  end
-
-In this case, we are using { and } instead of do and end to define the blocks. Just as
-before, the +run+ methods inside the blocks are called on the +Database+ object,
-which just executes the code on the underlying database.
-
-== Errors when running migrations
-
-Sequel attempts to run migrations inside of a transaction if the database supports
-transactional DDL statements.  On the databases that don't support transactional DDL
-statements, if there is an error while running a migration, it will not rollback the
-previous schema changes made by the migration.  In that case, you will
-need to update the database by hand.
-
-It's recommended to always run migrations on a test database and ensure they work
-before running them on any production database.
-
-== Transactions
-
-You can manually specify to use transactions on a per migration basis.  For example,
-if you want to force transaction use for a particular migration, call the transaction
-method in the Sequel.migration block:
-
-  Sequel.migration do
-    transaction
-    change do
-      # ...
-    end
-  end
-
-Likewise, you can disable transaction use via no_transaction:
-
-  Sequel.migration do
-    no_transaction
-    change do
-      # ...
-    end
-  end
-
-This is necessary in some cases, such as when attempting to use CREATE INDEX CONCURRENTLY
-on PostgreSQL (which supports transactional schema, but not that statement inside a
-transaction).
-
-You can also override the transactions setting at the migrator level, either by forcing
-transactions even if no_transaction is set, or by disabling transactions all together:
-
-  # Force transaction use
-  Sequel::Migrator.run(DB, '/path/to/migrations/dir', :use_transactions=>true)
-
-  # Disable use of transactions
-  Sequel::Migrator.run(DB, '/path/to/migrations/dir', :use_transactions=>false)
-
-== Migration files
-
-While you can create migration objects yourself and apply them manually, most of the
-benefit to using migrations come from using Sequel's +Migrator+, which is what the
-<tt>bin/sequel -m</tt> switch does.  Sequel's +Migrator+ expects that each migration
-will be in a separate file in a specific directory.  The <tt>-m</tt> switch requires an
-argument be specified that is the path to the directory containing the migration files.
-For example:
-
-  sequel -m db/migrations postgres://localhost/sequel_test
-
-will look in the <tt>db/migrations</tt> folder relative to the current directory,
-and run unapplied migrations on the PostgreSQL database sequel_test running on localhost.
-
-== Two separate migrators
-
-Sequel actually ships with two separate migrators.  One is the +IntegerMigrator+, the other is
-the +TimestampMigrator+.  They both have plusses and minuses:
-
-=== +IntegerMigrator+
-
-* Simpler, uses migration versions starting with 1
-* Doesn't allow duplicate migrations
-* Doesn't allow missing migrations by default
-* Just stores the version of the last migration run
-* Good for single developer or small teams with close
-  communication
-* Lower risk of undetected conflicting migrations
-* Requires manual merging of simultaneous migrations
-
-=== +TimeStampMigrator+
-
-* More complex, use migration versions where the version should
-  represent a timestamp
-* Allows duplicate migrations (since you could have multiple in a given second)
-* Allows missing migrations (since you obviously don't have one every second)
-* Stores the file names of all applied migrations
-* Good for large teams without close communication
-* Higher risk of undetected conflicting migrations
-* Does not require manual merging of simultaneous migrations
-
-=== Filenames
-
-In order for migration files to work with the Sequel, they must be specified as follows:
-
-  version_name.rb
-
-where <tt>version</tt> is an integer and <tt>name</tt> is a string which should be a very brief
-description of what the migration does.  Each migration class should contain 1 and only 1
-call to <tt>Sequel.migration</tt>.
-
-=== +IntegerMigrator+ Filenames
-
-These are valid migration names for the +IntegerMigrator+:
-
-  1_create_artists.rb
-  2_add_artist_location.rb
-
-The only problem with this naming format is that if you have more than 9 migrations, the 10th
-one will look a bit odd:
-
-  1_create_artists.rb
-  2_add_artist_location.rb
-  ...
-  9_do_something.rb
-  10_do_something_else.rb
-
-For this reasons, it's often best to start with 001 instead of 1, as that means you don't need
-to worry about that issue until the 1000th migration:
-
-  001_create_artists.rb
-  002_add_artist_location.rb
-  ...
-  009_do_something.rb
-  010_do_something_else.rb
-
-Migrations start at 1, not 0.  The migration version number 0
-is important though, as it is used to mean that all migrations should be unapplied (i.e. all
-+down+ blocks run).  In Sequel, you can do that with:
-
-  sequel -m db/migrations -M 0 postgres://localhost/sequel_test
-
-=== +TimestampMigrator+ Filenames
-
-With the +TimestampMigrator+, the version integer should represent a timestamp, though this isn't strictly
-required.
-
-For example, for <tt>5/10/2010 12:00:00pm</tt>, you could use any of the following formats:
-
-  # Date
-  20100510_create_artists.rb
-
-  # Date and Time
-  20100510120000_create_artists.rb
-
-  # Unix Epoch Time Integer
-  1273518000_create_artists.rb
-
-The important thing is that all migration files should be in the same format, otherwise when you
-update, it'll be difficult to make sure migrations are applied in the correct order, as well as
-be difficult to unapply some the affected migrations correctly.
-
-The +TimestampMigrator+ will be used if any filename in the migrations directory has a version
-greater than 20000101.  Otherwise, the +IntegerMigrator+ will be used.
-
-You can force the use of the +TimestampMigrator+ in the API by calling TimestampMigrator.apply
-instead of Migrator.apply.
-
-=== How to choose
-
-Basically, unless you need the features provided by the +TimestampMigrator+, stick with the
-+IntegerMigrator+, as it is simpler and makes it easier to detect possible errors.
-
-For a single developer, the +TimestampMigrator+ has no real benefits, so I would always recommend
-the +IntegerMigrator+.  When dealing with multiple developers, it depends on the size of the
-development team, the team's communication level, and the level of overlap between developers.
-
-Let's say Alice works on a new feature that requires a migration at the same time Bob works
-on a separate feature that requires an unrelated migration.  If both developers are committing
-to their own private respositories, when it comes time to merge, the +TimestampMigrator+ will not
-require any manually changes.  That's because Alice will have a migration such as
-<tt>20100512_do_this.rb</tt> and Bob will have one such as <tt>20100512_do_that.rb</tt>.
-
-If the +IntegerMigrator+ was used, Alice would have <tt>34_do_this.rb</tt> and Bob would have
-<tt>34_do_that.rb</tt>.  When the +IntegerMigrator+ was used, it would raise an exception due to
-the duplicate migration version.  The only way to fix it would be to renumber one of the two
-migrations, and have the affected developer manually modify their database.
-
-So for unrelated migrations, the +TimestampMigrator+ works fine.  However, let's say that the
-migrations are related, in such a way that if Bob's is run first, Alice's will fail.  In this
-case, the +TimestampMigrator+ would not raise an error when Bob merges Alice's changes, since
-Bob ran his migration first.  However, it would raise an error when Alice runs Bob's migration,
-and could leave the database in an inconsistent state if the database doesn't support transactional
-schema changes.
-
-With the +TimestampMigrator+, you are trading reliability for convenience.  That's possibly a valid
-trade, especially if simultaneous related schema changes by separate developers are unlikely, but
-you should give it some thought before using it.
-
-== Ignoring missing migrations
-
-In some cases, you may want to allow a migration in the database that does not exist in the filesystem (deploying to an older version of code without running a down migration when deploy auto-migrates, for example). If required, you can pass <tt>:allow_missing_migration_files => true<tt> as an option. This will stop errors from being raised if there are migrations in the database that do not exist in the filesystem.
-
-== Modifying existing migrations
-
-Just don't do it.
-
-In general, you should not modify any migration that has been run on the database and been committed to
-the source control repository, unless the migration contains an error that causes data loss.  As long
-as it is possible to undo the migration without losing data, you should just add another migration
-that undoes the actions of the previous bad migration, and maybe does the correct action afterward.
-
-The main problem with modifying existing migrations is that you will have to manually modify any
-databases that ran the migration before it was modified.  If you are a single developer, that may be
-an option, but certainly if you have multiple developers, it's a lot more work.
-
-== Creating a migration
-
-Sequel doesn't come with generators that create migrations for you.  However, creating a migration
-is as simple as creating a file with the appropriate filename in your migrations directory that
-contains a <tt>Sequel.migration</tt> call.  The minimal do-nothing migration is:
-
-  Sequel.migration{}
-
-However, the migrations you write should contain an +up+ block that does something, and a +down+ block that
-reverses the changes made by the +up+ block:
-
-  Sequel.migration do
-    up{}
-    down{}
-  end
-
-or they should use the reversible migrations feature with a +change+ block:
-
-  Sequel.migration do
-    change{}
-  end
-
-== What to put in your migration's +down+ block
-
-It's usually easy to determine what you should put in your migration's +up+ block,
-as it's whatever change you want to make to the database.  The +down+ block is
-less obvious.  In general, it should reverse the changes made by the +up+ block, which means
-it should execute the opposite of what the +up+ block does in the reverse order in which
-the +up+ block does it.  Here's an example where you are switching from having a single
-artist per album to multiple artists per album:
-
-  Sequel.migration do
-    up do
-      # Create albums_artists table
-      create_table(:albums_artists) do
-        foreign_key :album_id, :albums
-        foreign_key :artist_id, :artists
-        index [:album_id, :artist_id], :unique=>true
-      end
-
-      # Insert one row in the albums_artists table
-      # for each row in the albums table where there
-      # is an associated artist
-      self[:albums_artists].insert([:album_id, :artist_id],
-       self[:albums].select(:id, :artist_id).exclude(:artist_id=>nil))
-
-      # Drop the now unnecesssary column from the albums table
-      drop_column :albums, :artist_id
-    end
-    down do
-      # Add the foreign key column back to the artists table
-      alter_table(:albums){add_foreign_key :artist_id, :artists}
-
-      # If possible, associate each album with one of the artists
-      # it was associated with.  This loses information, but
-      # there's no way around that.
-      self[:albums_artists].
-       group(:album_id).
-       select{[album_id, max(artist_id).as(artist_id)]}.
-       having{artist_id >  0}.
-       all do |r|
-         self[:artists].
-          filter(:id=>r[:album_id]).
-          update(:artist_id=>r[:artist_id])
-       end
-
-      # Drop the albums_artists table
-      drop_table(:albums_artists)
-    end
-  end
-
-Note that the operations performed in the +down+ block are performed in the
-reverse order of how they are performed in the +up+ block.  Also note how it
-isn't always possible to reverse exactly what was done in the +up+ block.  You
-should try to do so as much as possible, but if you can't, you may want to have
-your +down+ block raise a <tt>Sequel::Error</tt> exception saying why the
-migration cannot be reverted.
-
-== Running migrations
-
-You can run migrations using the +sequel+ command line program that
-comes with Sequel.  If you use the <tt>-m</tt> switch, +sequel+ will
-run the migrator instead of giving you an IRB session.  The <tt>-m</tt>
-switch requires an argument that should be a path to a directory of migration
-files:
-
-  sequel -m relative/path/to/migrations postgres://host/database
-  sequel -m /absolute/path/to/migrations postgres://host/database
-
-If you do not provide a <tt>-M</tt> switch, +sequel+ will migrate to the latest
-version in the directory.  If you provide a <tt>-M</tt> switch, it should specify
-an integer version to which to migrate.
-
-  # Migrate all the way down
-  sequel -m db/migrations -M 0 postgres://host/database
-
-  # Migrate to version 10 (IntegerMigrator style migrations)
-  sequel -m db/migrations -M 10 postgres://host/database
-
-  # Migrate to version 20100510 (TimestampMigrator migrations using YYYYMMDD)
-  sequel -m db/migrations -M 20100510 postgres://host/database
-
-Whether or not migrations use the +up+ or +down+ block depends on the version
-to which you are migrating.  If you don't provide a <tt>-M</tt> switch, all
-unapplied migrations will be migrated up.  If you provide a <tt>-M</tt>, it will
-depend on which migrations that have been applied.  Applied migrations greater
-than that version will be migrated down, while unapplied migrations less than
-or equal to that version will be migrated up.
-
-== Running migrations from a Rake task
-
-You can also incorporate migrations into a Rakefile. Here's an example
-using integer migration versions.
-
-  namespace :db do
-    desc "Run migrations"
-    task :migrate, [:version] do |t, args|
-      require "sequel"
-      Sequel.extension :migration
-      db = Sequel.connect(ENV.fetch("DATABASE_URL"))
-      if args[:version]
-        puts "Migrating to version #{args[:version]}"
-        Sequel::Migrator.run(db, "db/migrations", target: args[:version].to_i)
-      else
-        puts "Migrating to latest"
-        Sequel::Migrator.run(db, "db/migrations")
-      end
-    end
-  end
-
-To migrate to the latest version, run:
-
-  rake db:migrate
-
-This Rake task takes an optional argument specifying the target
-version. To migrate to version 42, run:
-
-  rake db:migrate[42]
-
-== Verbose migrations
-
-By default, <tt>sequel -m</tt> operates as a well behaved command line utility
-should, printing out nothing if there is no error.  If you want to see the SQL
-being executed during a migration, as well as the amount of time that each
-migration takes, you can use the <tt>-E</tt> option to +sequel+ to set up a
-+Database+ logger that logs to +STDOUT+.  You can also log that same output to
-a file using the <tt>-l</tt> option with a log file name.
-
-== Using models in your migrations
-
-Just don't do it.
-
-It can be tempting to use models in your migrations, especially since it's easy
-to load them at the same time using the <tt>-L</tt> option to +sequel+.  However,
-this ties your migrations to your models, and makes it so that changes in your
-models can break old migrations.
-
-With Sequel, it should be easy to use plain datasets to accomplish pretty much
-anything you would want to accomplish in a migration.  Even if you have to
-copy some code from a model method into a migration itself, it's better than
-having your migration use models and call model methods.
-
-== Dumping the current schema as a migration
-
-Sequel comes with a +schema_dumper+ extension that dumps the current schema of
-the database as a migration to +STDOUT+ (which you can redirect to a file using
->).  This is exposed in the +sequel+ command line tool with the <tt>-d</tt> and
-<tt>-D</tt> switches.  <tt>-d</tt> dumps the schema in database independent
-format, while <tt>-D</tt> dumps the schema using a non-portable format, useful
-if you are using nonportable columns such as +inet+ in your database.
-
-Let's say you have an existing database and want to create a migration that
-would recreate the database's schema:
-
-  sequel -d postgres://host/database > db/migrations/001_start.rb
-
-or using a nonportable format:
-
-  sequel -D postgres://host/database > db/migrations/001_start.rb
-
-The main difference between the two is that <tt>-d</tt> will use the type methods
-with the database independent ruby class types, while <tt>-D</tt> will use
-the +column+ method with string types.
-
-Note that Sequel cannot dump constraints other than primary key and possibly
-foreign key constraints.  If you are using database features such
-as constraints or triggers, you should use your database's dump and restore
-programs instead of Sequel's schema dumper.
-
-You can take the migration created by the schema dumper to another computer
-with an empty database, and attempt to recreate the schema using:
-
-  sequel -m db/migrations postgres://host/database
-
-== Checking for Current Migrations
-
-In your application code, you may want to check that you are up to date in
-regards to migrations (i.e. you don't have any unapplied migrations).  Sequel
-offers two separate methods to do that.  The first is Sequel::Migrator.check_current.
-This method raises an exception if there are outstanding migrations that need to
-be run.  The second is Sequel::Migrator.is_current?, which returns true if there
-are no outstanding migrations, and false if there are outstanding migrations.
-
-If you want to ensure that your application code is up to date, you may want to
-add the following code after connecting to your database:
-
-  Sequel.extension :migration
-  Sequel::Migrator.check_current(DB, '/path/to/migrations')
-
-This will cause your application to raise an error when you start it if you have
-any outstanding migrations.
-
-== Old-style migration classes
-
-Before the <tt>Sequel.migration</tt> DSL was introduced, Sequel used classes
-for Migrations:
-
-  Class.new(Sequel::Migration) do
-    def up
-    end
-    def down
-    end
-  end
-
-or:
-
-  class DoSomething < Sequel::Migration
-    def up
-    end
-    def down
-    end
-  end
-
-This usage is discouraged in new code, but will continue to be supported indefinitely.
-It is not recommended to convert old-style migration classes to the <tt>Sequel.migration</tt>
-DSL, but it is recommended to use the <tt>Sequel.migration</tt> DSL for all new migrations.