RubyGems - asana2flowdock - Versions diffs - 1.0.0 → 1.1.0 - Mend

asana2flowdock 1.0.0 → 1.1.0

Files changed (1595) hide show

data/vendor/bundle/ruby/1.9.1/gems/sequel-4.15.0/doc/testing.rdoc DELETED Viewed

@@ -1,176 +0,0 @@
-= Testing with Sequel
-Whether or not you use Sequel in your application, you are usually going to want to have tests that ensure that your code works.  When you are using Sequel, it's helpful to integrate it into your testing framework, and it's generally best to run each test in its own transaction if possible.  That keeps all tests isolated from each other, and it's simple as it handles all of the cleanup for you.  Sequel doesn't ship with helpers for common libraries, as the exact code you need is often application-specific, but this page offers some examples that you can either use directly or build on.
-== Transactional tests
-These run each test in its own transaction, the recommended way to test.
-=== RSpec 1
-  class Spec::Example::ExampleGroup
-    def execute(*args, &block)
-      result = nil
-      Sequel::Model.db.transaction(:rollback=>:always, :auto_savepoint=>true){result = super(*args, &block)}
-      result
-    end
-  end
-=== RSpec 2, <2.8
-  class RSpec::Core::ExampleGroup
-    # Setting an around filter globally doesn't appear to work in <2.8,
-    # so set one up for each subclass.
-    def self.inherited(subclass)
-      super
-      subclass.around do |example|
-        Sequel::Model.db.transaction(:rollback=>:always, :auto_savepoint=>true){example.call}
-      end
-    end
-  end
-=== RSpec >=2.8
-  # Global around filters should work
-  RSpec.configure do |c|
-    c.around(:each) do |example|
-      DB.transaction(:rollback=>:always, :auto_savepoint=>true){example.run}
-    end
-  end
-=== Test::Unit
-  # Must use this class as the base class for your tests
-  class SequelTestCase < Test::Unit::TestCase
-    def run(*args, &block)
-      result = nil
-      Sequel::Model.db.transaction(:rollback=>:always, :auto_savepoint=>true){result = super}
-      result
-    end
-  end
-  # Or you could override the base implementation like this
-  class Test::Unit::TestCase
-    alias_method :_original_run, :run
-    def run(*args, &block)
-      result = nil
-      Sequel::Model.db.transaction(:rollback => :always, :auto_savepoint=>true) do
-        result = _original_run(*args, &block)
-      end
-      result
-    end
-  end
-=== MiniTest::Unit
-  # Add a subclass
-  # Must use this class as the base class for your tests
-  class SequelTestCase < MiniTest::Unit::TestCase
-    def run(*args, &block)
-      result = nil
-      Sequel::Model.db.transaction(:rollback=>:always, :auto_savepoint=>true){result = super}
-      result
-    end
-  end
-  # Or you could override the base implementation like this
-  class MiniTest::Unit::TestCase
-    alias_method :_original_run, :run
-    def run(*args, &block)
-      result = nil
-      Sequel::Model.db.transaction(:rollback => :always, :auto_savepoint=>true) do
-        result = _original_run(*args, &block)
-      end
-      result
-    end
-  end
-== Transactional testing with multiple databases
-You can use the Sequel.transaction method to run a transaction on multiple databases, rolling all of them back.  Instead of:
-  Sequel::Model.db.transaction(:rollback=>:always)
-Use Sequel.transaction with an array of databases:
-  Sequel.transaction([DB1, DB2, DB3], :rollback=>:always)
-== Nontransactional tests
-In some cases, it is not possible to use transactions.  For example, if you are testing a web application that is running in a separate process, you don't have access to that process's database connections, so you can't run your examples in transactions.  In that case, the best way to handle things is to cleanup after each test by deleting or truncating the database tables used in the test.
-The order in which you delete/truncate the tables is important if you are using referential integrity in your database (which you should be doing).  If you are using referential integrity, you need to make sure to delete in tables referencing other tables before the tables that are being referenced.  For example, if you have an +albums+ table with an +artist_id+ field referencing the +artists+ table, you want to delete/truncate the +albums+ table before the +artists+ table.  Note that if you have cyclic references in your database, you will probably need to write your own custom cleaning code.
-=== RSpec
-  class Spec::Example::ExampleGroup
-    after do
-      [:table1, :table2].each{|x| Sequel::Model.db.from(x).truncate}
-      # or
-      [:table1, :table2].each{|x| Sequel::Model.db.from(x).delete}
-    end
-  end
-=== Test::Unit
-  # Must use this class as the base class for your tests
-  class SequelTestCase < Test::Unit::TestCase
-    def teardown
-      [:table1, :table2].each{|x| Sequel::Model.db.from(x).truncate}
-      # or
-      [:table1, :table2].each{|x| Sequel::Model.db.from(x).delete}
-    end
-  end
-= Testing Sequel Itself
-Sequel has multiple separate test suites.  All test suites run under rspec >=1.3.
-== rake
-The default rake task runs Sequel's core, model, plugin, and extension specs, the same as <tt>rake spec spec_plugin</tt>.
-== rake spec
-The +spec+ rake task runs Sequel's core and model specs.  These specs use a mocked database connection, and test for specific SQL used and for generally correct behavior.
-== rake spec_plugin
-The +spec_plugin+ rake task runs the specs for the plugins and extensions that ship with Sequel.  These also use a mocked database connection, and operate very similarly to the general Sequel core and model specs.
-== rake spec_core_ext
-The +spec_core_ext+ rake task runs the specs for the core_extensions extension.  These are run separately from the other extension tests to make sure none of the other extensions require the core_extensions.
-== rake spec_bin
-The +spec_bin+ rake task runs the specs for bin/sequel.  These use an SQLite3 database, and require either the sqlite3 (non-JRuby) or jdbc-sqlite3 (JRuby) gem.
-== rake spec_<i>adapter</i> (e.g. rake spec_postgres)
-The <tt>spec_<i>adapter</i></tt> specs run against a real database connection with nothing mocked, and test for correct results.  They are slower than the standard specs, but they will catch errors that are mocked out by the default specs, as well as show issues that only occur on a certain database, adapter, or a combination of the two.
-These specs are broken down into two parts.  For each database, there are specific specs that only apply to that database, and these are called the adapter specs.  There are also shared specs that apply to all (or almost all) databases, these are called the integration specs. For database types that don't have specific adapter tests, you can use rake spec_integration to just run the shared integration tests.
-== Environment variables
-Sequel uses environment variables when testing to specify either the database to be tested or specify how testing should be done.  You can also specify the databases to test by copying spec/spec_config.rb.example to spec/spec_config.rb and modifying it.  See that file for details.  It may be necessary to use spec_config.rb as opposed to an environment variable if your database connection cannot be specified by a connection string.
-Sequel does not create test databases automatically, except for file-based databases such as SQLite/H2/HSQLDB/Derby.  It's up to the user to create the test databases manually and give Sequel a valid connection string in an environment variable (or setup the connection object in spec_config.rb).
-=== Connection Strings
-The SEQUEL_INTEGRATION_URL environment variable specifies the Database connection URL to use for the adapter and integration specs.  Additionally, when running the adapter specs, you can also use the SEQUEL_<i>ADAPTER</i>_URL environment variable (e.g. SEQUEL_POSTGRES_URL for spec_postgres).
-=== Other
-SEQUEL_COLUMNS_INTROSPECTION :: Use the columns_introspection extension when running the specs
-SEQUEL_CONNECTION_VALIDATOR :: Use the connection validator extension when running the specs
-SEQUEL_ERROR_SQL :: Use the error_sql extension when running the specs
-SEQUEL_NO_CACHE_ASSOCIATIONS :: Don't cache association metadata when running the specs
-SEQUEL_NO_CHECK_SQLS :: Don't check for specific SQL syntax when running the specs
-SEQUEL_NO_PENDING :: Don't mark any specs as pending, try running all specs (note, can cause lockups for some adapters)
-SEQUEL_NO_SKIP_PENDING :: On RSpec 3, run specs marked as pending, and fail the pending spec if it passes (note, can cause lockups for some adapters)
-SKIPPED_TEST_WARN :: Warn when skipping any tests because libraries aren't available

data/vendor/bundle/ruby/1.9.1/gems/sequel-4.15.0/doc/thread_safety.rdoc DELETED Viewed

@@ -1,17 +0,0 @@
-= Thread Safety
-Most Sequel usage (and all common Sequel usage) is thread safe by default.  Specifically, multiple threads can operate on Database instances, Dataset instances, and Model classes concurrently without problems.  In general, Database instance and Model classes are not modified after application startup, and modifying Dataset instances returns modified copies of the dataset instead of mutating it.
-== Connection Pool
-In order to allow multiple threads to operate on the same database at the same time, Sequel uses a connection pool.  The connection pool is designed so that a thread uses a connection for the minimum amount of time, returning the connection to the pool as soon as it is done using the connection.  If a thread requests a connection and the pool does not have an available connection, a new connection will be created.  If the maximum number of connections in the pool has already been reached, the thread will block (actually busy-wait) until a connection is available or the connection pool timeout has elapsed (in which case a PoolTimeout error will be raised).
-== Exceptions
-This is a small list of things that are specifically non thread-safe.  This is not an exhaustive list, there may be cases not mentioned here.
-1) Model instances: Model instances are not thread-safe unless they are frozen first.  Multiple threads should not operate on an unfrozen model instance concurrently.
-2) Model class modifications: Model class modifications, such as adding associations and loading plugins, are not designed to be thread safe.  You should not modify a class in one thread if any other thread can concurrently access it.  Model subclassing is designed to be thread-safe, so you create a model subclass in a thread and modify it safely.
-3) Dataset mutation methods: Dataset mutation methods are not thread safe, you should not call them on datasets that could be accessed by other threads.  It is safe to clone the dataset first inside a thread and call mutation methods on the cloned dataset.

data/vendor/bundle/ruby/1.9.1/gems/sequel-4.15.0/doc/transactions.rdoc DELETED Viewed

@@ -1,168 +0,0 @@
-= Database Transactions
-Sequel uses autocommit mode by default for all of its database adapters, so in general in Sequel if you want to use database transactions, you need to be explicit about it.  There are a few cases where transactions are used implicitly by default:
-* Dataset#import to insert many records at once
-* Model#save
-* Model#destroy
-* Migrations if the database supports transactional schema
-* A few model plugins
-Everywhere else, it is up to you to use a database transaction if you want to.
-== Basic Transaction Usage
-In Sequel, the <tt>Database#transaction</tt> method should be called if you want to use a database transaction.  This method must be called with a block.  If the block does not raise an exception, the transaction is committed:
-  DB.transaction do # BEGIN
-    DB[:foo].insert(1) # INSERT
-  end # COMMIT
-If the block raises a Sequel::Rollback exception, the transaction is rolled back, but no exception is raised outside the block:
-  DB.transaction do # BEGIN
-    raise Sequel::Rollback
-  end # ROLLBACK
-  # no exception raised
-If any other exception is raised, the transaction is rolled back, and the exception is raised outside the block:
-  DB.transaction do # BEGIN
-    raise ArgumentError
-  end # ROLLBACK
-  # ArgumentError raised
-If you want Sequel::Rollback exceptions to be reraised, use the <tt>:rollback => :reraise</tt> option:
-  DB.transaction(:rollback => :reraise) do # BEGIN
-    raise Sequel::Rollback
-  end # ROLLBACK
-  # Sequel::Rollback raised
-If you always want to rollback (useful for testing), use the <tt>:rollback => :always</tt> option:
-  DB.transaction(:rollback => :always) do # BEGIN
-    DB[:foo].insert(1) # INSERT
-  end # ROLLBACK
-  # no exception raised
-If you want to check whether you are currently in a transaction, use the Database#in_transaction? method:
-  DB.in_transaction? # false
-  DB.transaction do
-    DB.in_transaction? # true
-  end
-== Transaction Hooks
-You can add hooks to an in progress transaction that are called after the transaction commits or rolls back:
-  x = nil
-  DB.transaction do
-    DB.after_commit{x = 1}
-    DB.after_rollback{x = 2}
-    x # nil
-  end
-  x # 1
-  x = nil
-  DB.transaction do
-    DB.after_commit{x = 1}
-    DB.after_rollback{x = 2}
-    raise Sequel::Rollback
-  end
-  x # 2
-== Nested Transaction Calls / Savepoints
-You can nest calls to transaction, which by default just reuses the existing transaction:
-  DB.transaction do # BEGIN
-    DB.transaction do
-      DB[:foo].insert(1) # INSERT
-    end
-  end # COMMIT
-You can use the <tt>:savepoint => true</tt> option in the inner transaction to explicitly use a savepoint (if the database supports it):
-  DB.transaction do # BEGIN
-    DB.transaction(:savepoint => true) do # SAVEPOINT
-      DB[:foo].insert(1) # INSERT
-    end # RELEASE SAVEPOINT
-  end # COMMIT
-You can use the <tt>:auto_savepoint => true</tt> option in the outer transaction to explicitly use a savepoint in the inner transaction (if the database supports it):
-  DB.transaction(:auto_savepoint => true) do # BEGIN
-    DB.transaction do # SAVEPOINT
-      DB[:foo].insert(1) # INSERT
-    end # RELEASE SAVEPOINT
-  end # COMMIT
-If a Sequel::Rollback exception is raised inside the savepoint block, it will only rollback to the savepoint:
-  DB.transaction do # BEGIN
-    DB.transaction(:savepoint => true) do # SAVEPOINT
-      raise Sequel::Rollback
-    end # ROLLBACK TO SAVEPOINT
-    # no exception raised
-  end # COMMIT
-Other exceptions, unless rescued inside the outer transaction block, will rollback the savepoint and the outer transactions, since they are reraised by the transaction code:
-  DB.transaction do # BEGIN
-    DB.transaction(:savepoint => true) do # SAVEPOINT
-      raise ArgumentError
-    end # ROLLBACK TO SAVEPOINT
-  end # ROLLBACK
-  # ArgumentError raised
-== Prepared Transactions / Two-Phase Commit
-Sequel supports database prepared transactions on PostgreSQL, MySQL, and H2.  With prepared transactions, at the end of the transaction, the transaction is not immediately committed (it acts like a rollback).  Later, you can call +commit_prepared_transaction+ to commit the transaction or +rollback_prepared_transaction+ to roll the transaction back.  Prepared transactions are usually used with distributed databases to make sure all databases commit the same transaction or none of them do.
-To use prepared transactions in Sequel, you provide a string as the value of the :prepare option:
-  DB.transaction(:prepare => 'foo') do # BEGIN
-    DB[:foo].insert(1) # INSERT
-  end # PREPARE TRANSACTION 'foo'
-Later, you can commit the prepared transaction:
-  DB.commit_prepared_transaction('foo')
-or roll the prepared transaction back:
-  DB.rollback_prepared_transaction('foo')
-== Transaction Isolation Levels
-The SQL standard supports 4 isolation levels: READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ, and SERIALIZABLE.  Not all databases implement the levels as specified in the standard (or implement the levels at all), but on most databases, you can specify which transaction isolation level you want to use via the :isolation option to <tt>Database#transaction</tt>.  The isolation level is specified as one of the following symbols: :uncommitted, :committed, :repeatable, and :serializable.  Using this option make Sequel use the correct transaction isolation syntax for your database:
-  DB.transaction(:isolation => :serializable) do # BEGIN
-    # SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
-    DB[:foo].insert(1) # INSERT
-  end # COMMIT
-== Automatically Restarting Transactions
-Sequel offers the ability to automatically restart transactions if specific types of errors are detected.  For example, if you want to automatically restart a transaction if a serialization failure is detected:
-  DB.transaction(:isolation => :serializable, :retry_on=>[Sequel::SerializationFailure]) do
-    ModelClass.find_or_create(:name=>'Foo')
-  end
-At the serializable transaction isolation level, find_or_create may raises a Sequel::SerializationFailure exception if multiple threads simultaneously run that code.  With the :retry_on option set, the transaction will be automatically retried until it succeeds.
-Note that automatic retrying should not be used unless the entire transaction
-block is idempotent, as otherwise it can cause non-idempotent
-behavior to execute multiple times.  For example, with the following code:
-  DB.transaction(:isolation => :serializable, :retry_on=>[Sequel::SerializationFailure]) do
-    logger.info 'Ensuring existence of ModelClass with name Foo'
-    ModelClass.find_or_create(:name=>'Foo')
-  end
-The logger.info method will be called multiple times if there is a serialization failure.
-The :num_retries option can be used to set the maxmimum number of times to retry.  It is set to 5 times by default.

data/vendor/bundle/ruby/1.9.1/gems/sequel-4.15.0/doc/validations.rdoc DELETED Viewed

@@ -1,540 +0,0 @@
-= Model Validations
-This guide is based on http://guides.rubyonrails.org/activerecord_validations_callbacks.html
-== Overview
-This guide is designed to teach you how to use Sequel::Model's validation support.  It attempts
-to explain how Sequel's validation support works, what validations are
-useful for, and how to use the +validation_helpers+ plugin to add specific
-types of validations to your models.
-== Why Validations?
-Validations are primarily useful for associating error messages to display to the user
-with specific attributes on the model.  It is also possible to use them to enforce
-data integrity for model instances, but that's not a recommended use unless
-the only way to modify the database is through model instances, or you have
-complex data integrity requirements that aren't possible to specify via
-database-level constraints.
-== Data Integrity
-Data integrity is best handled by the database itself.  For example, if you have
-a date column that should never contain a NULL value, the column should be
-specified in the database as NOT NULL.  If you have an integer column that should
-only have values from 1 to 10, there should be a CHECK constraint that ensures
-that the value of that column is between 1 and 10.  And if you have a varchar
-column where the length of the entries should be between 2 and 255, you should
-be setting the size of the varchar column to 255, and using a CHECK constraint
-to ensure that all values have at least two characters.
-Unfortunately, sometimes there are situations where that is not possible.  For
-example, if you are using MySQL and don't have control over the database configuration,
-it's possible that if you attempt to insert a string with 300 characters into a
-varchar(255) field, then MySQL may just silently truncate it for you, instead of
-raising an error.  In that case, it may be necessary to use a model validation
-to enforce the database integrity.
-Also, in some cases you may have data integrity requirements that are difficult to
-enforce via database constraints, especially if you are targetting multiple
-database types.
-Finally, validations are generally easier to write than database constraints,
-so if data integrity isn't of great importance, using validations to provide minimal
-data integrity is probably fine.
-== Usage
-Regardless of whether you are using validations for data integrity or just for
-error messages, the usage is the same.  Whenever you attempt to save a model
-instance, before sending the INSERT or UPDATE query to the database,
-<tt>Sequel::Model</tt> will attempt to validate the instance by calling
-+validate+.  If +validate+ does not add any errors to the object, the object is
-considered valid, and <tt>valid?</tt> will return true.  If +validate+ adds any errors
-to the object, <tt>valid?</tt> will return false, and the save will either raise
-a <tt>Sequel::ValidationFailed</tt> exception (the default), or return nil (if +raise_on_save_failure+
-is false).
-By validating the object before sending the database query, Sequel attempts to
-ensure that invalid objects are not saved in the database.  However, if you
-are not enforcing the same validations in the database via constraints, it's
-possible that invalid data can get added to the database via some other method.
-This leads to odd cases such as retrieving a model object from the database,
-not making any changes to it, attempting to save it, and having the save
-raise an error.
-== Skipping Validations
-<tt>Sequel::Model</tt> uses the +save+ method to save model objects, and all
-saving of model objects passes through the +save+ method.  This means that all
-saving of model objects goes through the validation process.
-The only way to skip validations when saving a model object is to pass the
-<tt>:validate => false</tt> option to +save+. If you use that option, +save+ will
-not attempt to validate the object before saving it.
-Note that it's always possible to update the instance's database row without using
-+save+, by using a dataset to update it.  Validations will only be run if you call
-+save+ on the model object, or another model method that calls +save+.  For example,
-the +create+ class method instantiates a new instance of the model, and then calls
-+save+, so it validates the object.  However, the +insert+ class method is a dataset
-method that just inserts the raw hash into the database, so it doesn't validate the
-object.
-== <tt>valid?</tt> and +validate+
-<tt>Sequel::Model</tt> uses the <tt>valid?</tt> method to check whether or not a
-model instance is valid.  This method should not be overridden.  Instead, the
-+validate+ method should be overridden to add validations to the model:
-  class Album < Sequel::Model
-    def validate
-      super
-      errors.add(:name, 'cannot be empty') if !name || name.empty?
-    end
-  end
-  Album.new.valid? # false
-  Album.new(:name=>'').valid? # false
-  Album.new(:name=>'RF').valid? # true
-If the <tt>valid?</tt> method returns false, you can call the +errors+ method to
-get an instance of <tt>Sequel::Model::Errors</tt> describing the errors on the model:
-  a = Album.new
-  # => #<Album @values={}>
-  a.valid?
-  # => false
-  a.errors
-  # => {:name=>["cannot be empty"]}
-You may notice that the +errors+ method appears to return a hash.  That's because
-<tt>Sequel::Model::Errors</tt> is a subclass of Hash.
-Note that calling the +errors+ method before the <tt>valid?</tt> method will result
-in an +errors+ being empty:
-  Album.new.errors
-  # => {}
-So just remember that you shouldn't check +errors+ until after you call <tt>valid?</tt>.
-<tt>Sequel::Model::Errors</tt> has some helper methods that make it easy to get an array of
-all of the instance's errors, or for checking for errors on a specific attribute.  These
-will be covered later in this guide.
-== +validation_helpers+
-While <tt>Sequel::Model</tt> does provide a validations framework, it does not define
-any built-in validation helper methods that you can call.  However, Sequel ships with a
-plugin called +validation_helpers+ that handles most basic validation needs.  So instead of
-specifying validations like this:
-  class Album < Sequel::Model
-    def validate
-      super
-      errors.add(:name, 'cannot be empty') if !name || name.empty?
-      errors.add(:name, 'is already taken') if name && new? && Album[:name=>name]
-      errors.add(:website, 'cannot be empty') if !website || website.empty?
-      errors.add(:website, 'is not a valid URL') unless website =~ /\Ahttps?:\/\//
-    end
-  end
-You can call simple methods such as:
-  class Album < Sequel::Model
-    plugin :validation_helpers
-    def validate
-      super
-      validates_presence [:name, :website]
-      validates_unique :name
-      validates_format /\Ahttps?:\/\//, :website, :message=>'is not a valid URL'
-    end
-  end
-Other than +validates_unique+, which has it's own API, the methods defined by
-+validation_helpers+ have one of the following two APIs:
-<tt>(atts, opts={})</tt>:: For methods such as +validates_presence+, which do not
-                           take an additional argument.
-<tt>(arg, atts, opts={})</tt>:: For methods such as +validates_format+, which take an
-                                additional argument.
-For both of these APIs, +atts+ is either a column symbol or array of column symbols,
-and +opts+ is an optional options hash.
-The following methods are provided by +validation_helpers+:
-=== +validates_presence+
-This is probably the most commonly used helper method, which checks if the specified attributes are not blank.  In general, if an object responds to <tt>blank?</tt>, it calls the method to determine if the object is blank.  Otherwise, nil is considered blank, empty strings or strings that just contain whitespace are blank, and objects that respond to <tt>empty?</tt> and return true are considered blank.  All other objects are considered non-blank for the purposes of +validates_presence+.  This means that +validates_presence+ is safe to use on boolean columns where you want to ensure that either true or false is used, but not NULL.
-  class Album < Sequel::Model
-    def validate
-      super
-      validates_presence [:name, :website, :debut_album]
-    end
-  end
-=== +validates_not_null+
-This is similar to +validates_presence+, but only checks for NULL/nil values, allowing other blank objects such as empty strings or strings with just whitespace.
-=== +validates_format+
-+validates_format+ is used to ensure that the string value of the specified attributes matches the specified regular expression.  It's useful for checking that fields such as email addresses, URLs, UPC codes, ISBN codes, and the like, are in a specific format.  It can also be used to validate that only certain characters are used in the string.
-  class Album < Sequel::Model
-    def validate
-      super
-      validates_format /\A\d\d\d-\d-\d{7}-\d-\d\z/, :isbn
-      validates_format /\a[0-9a-zA-Z:' ]+\z/, :name
-    end
-  end
-=== +validates_exact_length+, +validates_min_length+, +validates_max_length+, +validates_length_range+
-These methods all deal with ensuring that the length of the specified attribute matches the criteria specified by the first argument to the method.  +validates_exact_length+ is for checking that the length of the attribute is equal to that value, +validates_min_length+ is for checking that the length of the attribute is greater than or equal to that value, +validates_max_length+ is for checking that the length of the attribute is less than or equal to that value, and +validates_length_range+ is for checking that the length of the attribute falls in the value, which should be a range or another object that responds to <tt>include?</tt>.
-  class Album < Sequel::Model
-    def validate
-      super
-      validates_exact_length 17, :isbn
-      validates_min_length 3, :name
-      validates_max_length 100, :name
-      validates_length_range 3..100, :name
-    end
-  end
-=== +validates_integer+, +validates_numeric+
-These methods check that the specified attributes can be valid integers or valid floats.  +validates_integer+ tests the attribute value using <tt>Kernel.Integer</tt> and +validates_numeric+ tests the attribute using <tt>Kernel.Float</tt>.  If the Kernel methods raise an exception, the validation fails, otherwise it succeeds.
-  class Album < Sequel::Model
-    def validate
-      super
-      validates_integer :copies_sold
-      validates_numeric :replaygain
-    end
-  end
-=== +validates_includes+
-+validates_includes+ checks that the specified attributes are included in the first argument to the method, which is usually an array, but can be any object that responds to <tt>include?</tt>.
-  class Album < Sequel::Model
-    def validate
-      validates_includes [1, 2, 3, 4, 5], :rating
-    end
-  end
-=== +validates_type+
-+validates_type+ checks that the specified attributes are instances of the class specified in the first argument.  The class can be specified as the class itself, or as a string or symbol with the class name, or as a an array of classes.
-  class Album < Sequel::Model
-    def validate
-      super
-      validates_type String, [:name, :website]
-      validates_type :Artist, :artist
-      validates_type [String, Integer], :foo
-    end
-  end
-=== +validates_schema_types+
-+validates_schema_types+ uses the database metadata for the model's table to determine which ruby type(s) should be used for the given database type, and calls +validates_type+ with that ruby type.  It's designed to be used with the <tt>raise_on_typecast_failure = false</tt> setting (the default starting in Sequel 4).  <tt>raise_on_typecast_failure = false</tt>, Sequel attempts to typecast values, but silently ignores any errors raised:
-  Album.raise_on_typecast_failure = false
-  album = Album.new
-  album.copies_sold = 'banana'
-  album.copies_sold # => 'banana'
-When <tt>raise_on_typecast_failure = false</tt>, you can call +validates_schema_types+ with all columns.  If any of those columns has a value that doesn't match the type that Sequel expects, it's probably because the column was set and Sequel was not able to typecast it correctly, which means it probably isn't valid.  For example, let's say that you want to check that a couple of columns contain valid dates:
-  class Album < Sequel::Model
-    self.raise_on_typecast_failure = false
-    def validate
-      super
-      validates_schema_types [:release_date, :record_date]
-    end
-  end
-  album = Album.new
-  album.release_date = 'banana'
-  album.release_date # => 'banana'
-  album.record_date = '2010-05-17'
-  album.record_date # => #<Date: 4910667/2,0,2299161>
-  album.valid? # => false
-  album.errors # => {:release_date=>["is not a valid date"]}
-For web applications, you usually want the <tt>raise_on_typecast_failure = false</tt> setting, so that you can accept all of the input without raising an error, and then present the user with all error messages.  Without the setting, if the user submits any invalid data, Sequel will immediately raise an error.  +validates_schema_types+ is helpful because it allows you to check for typecasting errors on columns, and provides a good default error message stating that the attribute is not of the expected type.
-=== +validates_unique+
-+validates_unique+ has a similar but different API than the other +validation_helpers+ methods.  It takes an arbitrary number of arguments, which should be column symbols or arrays of column symbols.  If any argument is a symbol, Sequel sets up a unique validation for just that column.  If any argument is an array of symbols, Sequel sets up a unique validation for the combination of the columns.  This means that you get different behavior depending on whether you call the object with an array or with separate arguments.  For example:
-  validates_unique(:name, :artist_id)
-Will set up a 2 separate uniqueness validations.  It will make it so that no two albums can have the same name, and that each artist can only be associated with one album.  In general, that's probably not what you want.  You probably want it so that two albums can have the same name, unless they are by the same artist.  To do that, you need to use an array:
-  validates_unique([:name, :artist_id])
-That sets up a single uniqueness validation for the combination of the fields.
-You can mix and match the two approaches.  For example, if all albums should have a unique UPC, and no artist can have duplicate album names:
-  validates_unique(:upc, [:name, :artist_id])
-+validates_unique+ also accepts a block to scope the uniqueness constraint.  For example, if you want to ensure that all active albums have a unique name, but inactive albums can duplicate the name:
-  validates_unique(:name){|ds| ds.where(:active)}
-If you provide a block, it is called with the dataset to use for the uniqueness check, which you can then filter to scope the uniqueness validation to a subset of the model's dataset.
-You can also include an options hash as the last argument.  Unlike the other validations, the options hash for +validates_unique+ only recognizes for these options:
-:dataset :: The base dataset to use for the unique query, defaults to the model's dataset
-:message :: The message to use
-:only_if_modified :: Only check the uniqueness if the object is new or one of the columns has been modified.
-:where :: A callable object where call takes three arguments, a dataset,
-          the current object, and an array of columns, and should return
-          a modified dataset that is filtered to include only rows with
-          the same values as the current object for each column in the array.
-          This is useful any time the unique constraints are derived from
-          the columns and not the columns themselves (such as unique constraints
-          on lower(column)).
-+validates_unique+ is the only method in +validation_helpers+ that checks with the database.  Attempting to validate uniqueness outside of the database suffers from a race condition, so any time you want to add a uniqueness validation, you should make sure to add a uniqueness constraint or unique index on the underlying database table.  See the {"Migrations and Schema Modification" guide}[rdoc-ref:doc/migration.rdoc] for details on how to do that.
-== +validation_helpers+ Options
-All +validation_helpers+ methods except +validates_unique+ accept the following options:
-=== <tt>:message</tt>
-The most commonly used option, used to override the default validation message.  Can be either a string or a proc.  If a string, it is used directly.  If a proc, the proc is called and should return a string.  If the validation method takes an argument before the array of attributes, that argument is passed as an argument to the proc. The exception is the +validates_not_string+ method, which doesn't take an argument, but passes the schema type symbol as the argument to the proc.
-  class Album < Sequel::Model
-    def validate
-      super
-      validates_presence :copies_sold, :message=>'was not given'
-      validates_min_length 3, :name, :message=>proc{|s| "should be more than #{s} characters"}
-    end
-  end
-=== <tt>:allow_nil</tt>
-The <tt>:allow_nil</tt> option skips the validation if the attribute value is nil or if the attribute is not present.  It's commonly used when you have a +validates_presence+ method already on the attribute, and don't want multiple validation errors for the same attribute:
-  class Album < Sequel::Model
-    def validate
-      super
-      validates_presence :copies_sold
-      validates_integer :copies_sold, :allow_nil=>true
-    end
-  end
-Without the <tt>:allow_nil</tt> option to +validates_integer+, if the copies_sold attribute was nil, you would get two separate validation errors, instead of a single validation error.
-=== <tt>:allow_blank</tt>
-The <tt>:allow_blank</tt> is similar to the <tt>:allow_nil</tt> option, but instead of just skipping the attribute for nil values, it skips the attribute for all blank values.  For example, let's say that artists can have a website.  If they have one, it should be formatted like a URL, but it can be nil or an empty string if they don't have one.
-  class Album < Sequel::Model
-    def validate
-      super
-      validates_format /\Ahttps?:\/\//, :website, :allow_blank=>true
-    end
-  end
-  a = Album.new
-  a.website = ''
-  a.valid? # true
-=== <tt>:allow_missing</tt>
-The <tt>:allow_missing</tt> option is different from the <tt>:allow_nil</tt> option, in that instead of checking if the attribute value is nil, it checks if the attribute is present in the model instance's values hash.   <tt>:allow_nil</tt> will skip the validation when the attribute is in the values hash and has a nil value and when the attribute is not in the values hash.  <tt>:allow_missing</tt> will only skip the validation when the attribute is not in the values hash.  If the attribute is in the values hash but has a nil value, <tt>:allow_missing</tt> will not skip it.
-The purpose of this option is to work correctly with missing columns when inserting or updating records.  Sequel only sends the attributes in the values hash when doing an insert or update. If the attribute is not present in the values hash, Sequel doesn't specify it, so the database will use the table's default value when inserting the record, or not modify the value when saving it. This is different from having an attribute in the values hash with a value of nil, which Sequel will send as NULL. If your database table has a non NULL default, this may be a good option to use. You don't want to use allow_nil, because if the attribute is in values but has a value nil, Sequel will attempt to insert a NULL value into the database, instead of using the database's default.
-== Conditional Validation
-Because Sequel uses the +validate+ instance method to handle validation, making validations conditional is easy as it works exactly the same as ruby's standard conditionals.  For example, if you only want to validate an attribute when creating an object:
-  validates_presence :name if new?
-If you only want to validate the attribute when updating an existing object:
-  validates_integer :copies_sold unless new?
-Let's say you only to make a validation conditional on the status of the object:
-  validates_presence :name if status_id > 1
-  validates_integer :copies_sold if status_id > 3
-You can use all the standard ruby conditional expressions, such as +case+:
-  case status_id
-  when 1
-    validates_presence :name
-  when 2
-    validates_presence [:name, :artist_id]
-  when 3
-    validates_presence [:name, :artist_id, :copies_sold]
-  end
-You can make the input to some validations dependent on the values of another attribute:
-  validates_min_length(status_id > 2 ? 5 : 10, [:name])
-  validates_presence(status_id < 2 ? :name : [:name, :artist_id])
-Basically, there's no special syntax you have to use for conditional validations.  Just handle conditionals the way you would in other ruby code.
-== Default Error Messages
-These are the default error messages for all of the helper methods in +validation_helpers+:
-:exact_length :: is not #{arg} characters
-:format :: is invalid
-:includes :: is not in range or set: #{arg.inspect}
-:integer :: is not a number
-:length_range :: is too short or too long
-:max_length :: is longer than #{arg} characters
-:min_length :: is shorter than #{arg} characters
-:not_null :: is not present
-:numeric :: is not a number
-:schema_types :: is not a valid #{schema_type}
-:type :: is not a #{arg}
-:presence :: is not present
-:unique :: is already taken
-== Modifying the Default Options
-It's easy to modify the default options used by +validation_helpers+.  All of the default options are stored in the <tt>Sequel::Plugins::ValidationHelpers::DEFAULT_OPTIONS</tt> hash.  So you just need to modify that hash to change the default options.  One way to do that is to use <tt>merge!</tt> to update the hash:
-  Sequel::Plugins::ValidationHelpers::DEFAULT_OPTIONS.merge!(
-   :presence=>{:message=>'cannot be empty'},
-   :includes=>{:message=>'invalid option', :allow_nil=>true},
-   :max_length=>{:message=>lambda{|i| "cannot be more than #{i} characters"}, :allow_nil=>true},
-   :format=>{:message=>'contains invalid characters', :allow_nil=>true})
-This updates the default messages that will be used for the presence, includes, max_length, and format validations, and sets the default value of the <tt>:allow_nil</tt> option to true for the includes, max_length, and format validations.
-You can also override <tt>Sequel::Model#default_validation_helpers_options</tt> private method to override these settings on a per-model or even per-instance basis.
-== Custom Validations
-Just as the first validation example showed, you aren't limited to the validation methods defined by +validation_helpers+.  Inside the +validate+ method, you can add your own validations by adding to the instance's errors using <tt>errors.add</tt> whenever an attribute is not valid:
-  class Album < Sequel::Model
-    def validate
-      super
-      errors.add(:release_date, 'cannot be before record date') if release_date < record_date
-    end
-  end
-Just like conditional validations, with custom validations you are just using the standard ruby conditionals, and calling <tt>errors.add</tt> with the column symbol and the error message if you detect invalid data.
-It's fairly easy to create your own custom validations that can be reused in all your models.  For example, if there is a common need to validate that one column in the model comes before another column:
-  class Sequel::Model
-    def validates_after(col1, col2)
-      errors.add(col1, "cannot be before #{col2}") if send(col1) < send(col2)
-    end
-  end
-  class Album < Sequel::Model
-    def validate
-      super
-      validates_after(:release_date, :record_date)
-    end
-  end
-== Setting Validations for All Models
-Let's say you want to add some default validations that apply to all of your model classes.  It's fairly easy to do by overriding the +validate+ method in <tt>Sequel::Model</tt>, adding some validations to it, and if you override +validate+ in your model classes, just make sure to call +super+.
-  class Sequel::Model
-    def self.string_columns
-      @string_columns ||= columns.reject{|c| db_schema[c][:type] != :string}
-    end
-    def validate
-      super
-      validates_format(/\A[^\x00-\x08\x0e-\x1f\x7f\x81\x8d\x8f\x90\x9d]*\z/n,
-       model.string_columns,
-       :message=>"contains invalid characters")
-    end
-  end
-This will make sure that all string columns in the model are validated to make sure they don't contain any invalid characters.  Just remember that if you override the +validate+ method in your model classes, you need to call +super+:
-  class Album < Sequel::Model
-    def validate
-      super # Important!
-      validates_presence :name
-    end
-  end
-If you forget to call +super+, the validations that you defined in <tt>Sequel::Model</tt> will not be enforced.  It's a good idea to call super whenever you override one of <tt>Sequel::Model</tt>'s methods, unless you specifically do not want the default behavior.
-== <tt>Sequel::Model::Errors</tt>
-'
-As mentioned earlier, <tt>Sequel::Model::Errors</tt> is a subclass of Hash with a few special methods, the most common of which are described here:
-=== +add+
-+add+ is the method used to add error messages for a given column.  It takes the column symbol as the first argument and the error message as the second argument:
-  errors.add(:name, 'is not valid')
-=== +on+
-+on+ is a method usually used after validation has been completed, to determine if there were any errors on a given attribute.  It takes the column value, and returns an array of error messages if there were any, or nil if not:
-  errors.on(:name)
-If you want to make some validations dependent upon the results of other validations, you may want to use +on+ inside your validates method:
-  validates_integer(:release_date) if errors.on(:record_date)
-Here, you don't care about validating the release date if there were validation errors for the record date.
-=== +full_messages+
-+full_messages+ returns an array of error messages for the object.  It's commonly called after validation to get a list of error messages to display to the user:
-  album.errors
-  # => {:name=>["cannot be empty"]}
-  album.errors.full_messages
-  # => ["name cannot be empty"]
-Note that the column names used in the errors are used verbatim in the error messages.  If you want full control over the error messages, you can use +add+ with a literal string:
-  errors.add(:name, Sequel.lit("Album name is not valid"))
-  errors.full_messages
-  # => ["Album name is not valid"]
-Alternatively, feel free to override Sequel::Model::Errors#full_messages.  As long as it returns an array of strings, overridding it is completely safe.
-=== +count+
-+count+ returns the total number of error messages in the errors.
-  album.errors.count # => 1
-== Other Validation Plugins
-=== +constraint_validations+
-Sequel ships with a +constraint_validations+ plugin and extension, that allows you to setup constraints when creating your database tables, and have Model validations automatically created that mirror those constraints.
-=== +auto_validations+
-Autovalidations uses the not null and type information obtained from parsing the database schema, and the unique index information from parsing the database's index information, and automatically setting up not_null, schema_types, and unique validations.  If you don't require customizing validation messages on a per-column basis, it can DRY up a lot of validation code.
-=== +validation_class_methods+
-Sequel ships with the +validation_class_methods+ plugin, which uses class methods instead of instance methods to define validations.  It exists mostly for legacy compatibility, but it is still supported.