sequel 3.23.0 → 3.24.0

data/CHANGELOG

@@ -1,3 +1,67 @@
+=== 3.24.0 (2011-06-01)
+
+* Add prepared_statements_association plugin, for using prepared statements by default for regular association loading (jeremyevans)
+
+* Add prepared_statements_safe plugin, for making prepared statement use with models more safe (jeremyevans)
+
+* Add prepared_statements_with_pk plugin, for using prepared statements for dataset lookups by primary key (jeremyevans)
+
+* Fix bug in emulated prepared statement support not supporting nil or false as bound values (jeremyevans)
+
+* Add Dataset#unbind for unbinding values from a dataset, for use with creating prepared statements (jeremyevans)
+
+* Add prepared_statements plugin for using prepared statements for updates, inserts, deletes, and lookups by primary key (jeremyevans)
+
+* Make Dataset#[] for model datasets consider a single integer argument as a lookup by primary key (jeremyevans)
+
+* Add Dataset#with_pk for model datasets, for finding first record with matching primary key value (jeremyevans)
+
+* Add defaults_setter plugin for setting default values when initializing model instances (jeremyevans)
+
+* Add around hooks (e.g. around_save) to Sequel::Model (jeremyevans)
+
+* Add Model#initialize_set private method to ease extension writing (jeremyevans)
+
+* Only typecast bit fields to booleans on MSSQL, the MySQL bit type is a bitfield, not a boolean (jeremyevans)
+
+* Set SQL_AUTO_IS_NULL=0 by default when connecting to MySQL via the swift and jdbc adapters (jeremyevans)
+
+* Fix bug in multiple column IN/NOT IN emulation when a model dataset is used (jeremyevans)
+
+* Add support for filtering and excluding by association datasets (jeremyevans)
+
+* Fix literalization of boolean values in filters on SQLite and MSSQL (jeremyevans)
+
+* Add support for filtering and excluding by multiple associations (jeremyevans)
+
+* Add support for inverting some SQL::Constant instances such as TRUE, FALSE, NULL, and NOTNULL (jeremyevans)
+
+* Add support for excluding by associations to model datasets (jeremyevans)
+
+* The Sequel::Postgres.use_iso_date_format setting now only affects future Database objects (jeremyevans)
+
+* Add Sequel::Postgres::PG_NAMED_TYPES hash for extensions to register type conversions for non-standard types (jeremyevans, pvh)
+
+* Make create_table? use IF NOT EXISTS instead of using SELECT to determine existence, if supported (jeremyevans)
+
+* Fix bug in association_pks plugin when associated table has a different primary key column name (jfirebaugh)
+
+* Fix limiting rows when connecting to DB2 (semmons99)
+
+* Exclude columns from tables in the INFORMATION_SCHEMA when parsing table schema on JDBC (jeremyevans)
+
+* Fix limiting rows when connecting to Microsoft Access (jeremyevans)
+
+* Add Database#views for getting an array of symbols of view names for the database (jeremyevans, christian.michon)
+
+* Make Datbase#tables no longer include view names on MySQL (jeremyevans)
+
+* Convert Java CLOB objects to ruby strings when using the JDBC JTDS subadapter (christian.michon)
+
+* If Thread#kill is called on a thread with an open transaction, roll the transaction back on ruby 1.8 and rubinius (jeremyevans)
+
+* Split informix adapter into shared/specific parts, add JDBC informix subadapter (jeremyevans)
+
 === 3.23.0 (2011-05-02)
 
 * Migrate issue tracker from Google Code to GitHub Issues (jeremyevans)

data/doc/association_basics.rdoc

@@ -421,13 +421,51 @@ This doesn't just work for +many_to_one+ associations, it also works for
 
 Note that for +one_to_many+ and +many_to_many+ associations, you still
 use the plural form even though only a single model object is given.
-You cannot use an array of model objects as the value, only a single model
-object.  To use separate model objects for the same association, you can
-use the array form of condition specifiers:
 
-  Album.filter([[:tags, Tag[1]], [:tags, Tag[2]]])
+You can also exclude by associations:
 
-That will return albums associated with both tag 1 and tag 2.
+  Album.exclude(:artist=>@artist).all
+  
+This will return all albums not by that artist.
+
+You can also provide an array with multiple model objects:
+
+  Album.filter(:artist=>[@artist1, @artist2]).all
+
+Similar to using an array of integers or strings, this will return
+all albums whose artist is one of those two artists.  You can also
+use +exclude+ if you want all albums not by either of those artists:
+
+  Album.exclude(:artist=>[@artist1, @artist2]).all
+
+If you are using a +one_to_many+ or +many_to_many+ association, you
+may want to return records where the records matches all of multiple
+records, instead of matching any of them.  For example:
+
+  Album.filter(:tags=>[@tag1, @tag2])
+  
+This matches albums that are associated with either @tag1 or @tag2 or
+both.  If you only want ones that you are associated with both, you can
+use separate filter calls:
+
+  Album.filter(:tags=>@tag1).filter(:tags=>@tag2)
+
+Or the the array form of condition specifiers:
+
+  Album.filter([[:tags, @tag1], [:tags, @tag2]])
+
+These will return albums associated with both @tag1 and @tag2.
+
+You can also provide a dataset value when filtering by associations:
+
+  Album.filter(:artist=>Artist.filter(:name.like('A%'))).all
+
+This will return all albums whose artist starts with 'A'. Like
+the other forms, this can be inverted:
+
+  Album.exclude(:artist=>Artist.filter(:name.like('A%'))).all
+ 
+This will return all albums whose artist does not start with 'A'.
 
 Note that filtering by associations only works correctly for simple
 associations (ones without conditions).

data/doc/model_hooks.rdoc

@@ -4,7 +4,7 @@ This guide is based on http://guides.rubyonrails.org/activerecord_validations_ca
 
 == Overview
 
-Model hooks, also known as model callbacks, are used to specify actions that occur at a given point in a model instance's lifecycle, such as before or after the model object is saved, created, updated, destroyed, or validated.
+Model hooks, also known as model callbacks, are used to specify actions that occur at a given point in a model instance's lifecycle, such as before or after the model object is saved, created, updated, destroyed, or validated.  There are also around hooks for all types, which wrap the before hooks, the behavior, and the after hooks.
 
 == Basic Usage
 
@@ -23,41 +23,51 @@ The one important thing to note here is the call to +super+ inside the hook.  Wh
 
 Sequel calls hooks in the following order when saving/creating a new object (one that does not already exist in the database):
 
-* +before_validation+
-* +after_validation+
-* +before_save+
-* +before_create+
-* INSERT QUERY
-* +after_create+
-* +after_save+
+* +around_validation+
+  * +before_validation+
+  * +validate+ method called
+  * +after_validation+
+* +around_save+
+  * +before_save+
+  * +around_create+
+    * +before_create+
+    * INSERT QUERY
+    * +after_create+
+  * +after_save+
 
 Sequel calls hooks in the following order when saving an existing object:
 
-* +before_validation+
-* +after_validation+
-* +before_save+
-* +before_update+
-* UPDATE QUERY
-* +after_update+
-* +after_save+
+* +around_validation+
+  * +before_validation+
+  * +validate+ method called
+  * +after_validation+
+* +around_save+
+  * +before_save+
+  * +around_update+
+    * +before_update+
+    * INSERT QUERY
+    * +after_update+
+  * +after_save+
 
-Note that all of the hook calls are the same, except that +before_create+ and +after_create+ are used for a new object, and +before_update+ and +after_update+ are used for an existing object.  Note that +before_save+ is called in both cases, before either +before_create+ or +before_update+, and that +after_save+ is also called in both cases, after either +after_create+ or +after_update+.
+Note that all of the hook calls are the same, except that +around_create+, +before_create+ and +after_create+ are used for a new object, and +around_update+, +before_update+ and +after_update+ are used for an existing object.  Note that +around_save+, +before_save+, and +after_save+ are called in both cases.
 
 Also note that the validation hooks are not called if the <tt>:validate => false</tt> option is passed to save.  However, the validation hooks are called if you call <tt>Model#valid?</tt> manually:
 
-* +before_validation+
-* VALIDATION HAPPENS
-* +after_validation+
+* +around_validation+
+  * +before_validation+
+  * +validate+ method called
+  * +after_validation+
 
 Sequel calls hooks in the following order when destroying an existing object:
 
-* +before_destroy+
-* DELETE QUERY
-* +after_destroy+
+* +around_destroy+
+  * +before_destroy+
+  * DELETE QUERY
+  * +after_destroy+
 
 Note that these hooks are only called when using <tt>Model#destroy</tt>, they are not called if you use <tt>Model#delete</tt>.
 
-<tt>Sequel::Model</tt> does support one additional hook, +after_intialize+, which is called after the model object has been initalized.  It can be used to set default attribute values for new objects, since by default new <tt>Sequel::Model</tt> objects have no attributes, and the attributes are not filled in until the model object is saved.  You should be careful when you are using +after_initialize+, since it is called for every created record.  So if you run a query that returns 1000 model objects, it will be called 1000 times.
+<tt>Sequel::Model</tt> does support one additional hook, +after_intialize+, which is called after the model object has been initalized.  It can be used to set default attribute values for new objects, since by default new <tt>Sequel::Model</tt> objects have no attributes, and the attributes are not filled in until the model object is saved.  You should be careful when you are using +after_initialize+, since it is called for every created record.  So if you run a query that returns 1000 model objects, it will be called 1000 times.  If you only want to change the behavior for new records, you can override the +initialize_set+ private method, which is called with the hash passed to +initialize+. 
 
 == Running Hooks
 
@@ -98,7 +108,7 @@ If you want to insert a row into the model's table without running the creation
 
 == Halting Hook Processing
 
-Sequel uses a convention that if any <tt>before_*</tt> hook method returns false (but not nil), that the action will be canceled.  You can use this to implement validation-like behavior, that will run even if validations are skipped.  For example:
+Sequel uses a convention that if any <tt>before_*</tt> hook method returns false (but not nil), that the action will be canceled and a <tt>Sequel::HookFailed</tt> raised (or +nil+ to be returned by +save+ if +raise_on_save_failure+ is +false+).  You can use this to implement validation-like behavior, that will run even if validations are skipped.  For example:
 
   class Album < Sequel::Model
     def before_save
@@ -107,9 +117,9 @@ Sequel uses a convention that if any <tt>before_*</tt> hook method returns false
     end
   end
 
-While returning false is not really recommended, you should be aware of this behavior so that you do not inadvertently return false.
+While returning false is not really recommended, you should be aware of this behavior so that you do not inadvertently return false.  For around hooks, neglecting to call +super+ halts hook processing in the same way as returning +false+ in a before hook.  You can't halt hook processing in after hooks, since by then the main processing has already taken place.
 
-By default, Sequel runs hooks other than validation hooks inside a transaction, so if you abort the hook by returning false in a before hook or by raising an exception in the hook, Sequel will rollback the transaction.  However, note that the implicit use of transactions when saving and destroying model objects is conditional (it depends on the model instance's +use_transactions+ setting).
+By default, Sequel runs hooks other than validation hooks inside a transaction, so if you abort the hook by returning false in a before hook or by raising an exception in any hook, Sequel will rollback the transaction.  However, note that the implicit use of transactions when saving and destroying model objects is conditional (it depends on the model instance's +use_transactions+ setting and the <tt>:transaction</tt> option passed to save).
 
 == Conditional Hooks
 
@@ -183,6 +193,7 @@ This allows the following general principles to be true:
 
 * before hooks are run in reverse order of inclusion
 * after hooks are run in order of inclusion
+* returning false in any before hook will pass the false value down the hook method chain, halting the hook processing.
 
 So if you define the same before hook in both a model and a plugin that the model uses, the hooks will be called in this order:
 
@@ -193,6 +204,32 @@ So if you define the same before hook in both a model and a plugin that the mode
 
 Again, Sequel does not enforce that, and you are free to call +super+ in an order other than the recommended one (just make sure that you call it).
 
+== Around Hooks
+
+Around hooks should only be used if you cannot accomplish the same results with before and after hooks.  For example, if you want to catch database errors caused by the +INSERT+ or +UPDATE+ query when saving a model object and raise them as validation errors, you cannot use a before or after hook.  You have use an +around_save+ hook:
+
+  class Album < Sequel::Model
+    def around_save
+      super
+    rescue Sequel::DatabaseError => e
+      # parse database error, set error on self, and reraise a Sequel::ValidationFailed
+    end
+  end
+ 
+Likewise, let's say that upon retrieval, you associate an object with a file descriptor, and you want to ensure that the file descriptor is closed after the object is saved to the database.  Let's assume you are always saving the object and you are not using validations.  You could not use an +after_save+ hook safely, since if the database raises an error, the +after_save+ method will not be called.  In this case, an +around_save+ hook is also the correct choice:
+
+  class Album < Sequel::Model
+    def around_save
+      super
+    ensure
+      @file_descriptor.close
+    end
+  end
+
 == +hook_class_methods+
 
-While it's recommended to write your hooks as instance methods, Sequel ships with a +hook_class_methods+ plugin that allows you to define hooks via class methods. It exists mostly for legacy compatibility, but is still supported. 
+While it's recommended to write your hooks as instance methods, Sequel ships with a +hook_class_methods+ plugin that allows you to define hooks via class methods. It exists mostly for legacy compatibility, but is still supported.  However, it does not implement around hooks.
+
+== +instance_hooks+
+
+Sequel also ships with an +instance_hooks+ plugin that allows you to define before and after hooks on a per instance basis.  It's very useful as it allows you to delay action on an instance until before or after saving.  This can be important if you want to modify a group of related objects together (which is how the +nested_attributes+ plugin uses +instance_hooks+).

data/doc/prepared_statements.rdoc

@@ -5,7 +5,7 @@ database you are using, the Sequel prepared statement/bound variable API remains
 the same.  There is native support for prepared statements/bound variables on
 the following databases:
 
-* PostgreSQL (using the pg driver, requires type specifiers)
+* PostgreSQL (using the pg driver, may require type specifiers)
 * MySQL (prepared statements only, as the ruby mysql driver doesn't support
   bound variables)
 * SQLite
@@ -13,6 +13,10 @@ the following databases:
 
 Support on other databases is emulated via string interpolation.
 
+You can use the prepared_statements model plugin to automatically use prepared
+statements for some common model actions such as saving or deleting a model
+instance, or looking up a model based on a primary key.
+
 == Placeholders
 
 Generally, when using prepared statements (and certainly when using bound
@@ -74,9 +78,9 @@ and update queries, the hash to insert/update is passed to +prepare+:
 
 If you are using the ruby-postgres or postgres-pr driver, PostgreSQL uses the
 default emulated support.  If you are using ruby-pg, there is native support,
-but it requires type specifiers most of the time.  This is easy if you have
+but it may require type specifiers.  This is easy if you have
 direct control over the SQL string, but since Sequel abstracts that, the types
-have to be specified another way.  This is done by adding a __* suffix to the
+can be specified another way.  This is done by adding a __* suffix to the
 placeholder symbol (e.g. :$name__text, which will be compiled to "$1::text"
 in the SQL).  Prepared statements are always server side.
 
@@ -87,7 +91,7 @@ statements are cached per connection.
 
 === MySQL
 
-The MySQL ruby driver does not support bound variables, so the the bound
+The MySQL ruby driver does not support bound variables, so the bound
 variable methods fall back to string interpolation.  It uses server side
 prepared statements.
 

data/doc/reflection.rdoc

@@ -16,13 +16,19 @@ In some cases, the adapter scheme will be the same as the database to which you
 
 == Tables in the Database
 
-On many database types/adapters, Database#tables exists and gives an array of table name symbols:
+Database#tables gives an array of table name symbols:
+
+  DB.tables # [:table1, :table2, :table3, ...]
+
+== Views in the Database
+
+Database#views and gives an array of view name symbols:
 
   DB.tables # [:table1, :table2, :table3, ...]
 
 == Indexes on a table
 
-On a few database types/adapters, Database#indexes takes a table name gives a hash of index information.  Keys are index names, values are subhashes with the keys :columns and :unique :
+Database#indexes takes a table name gives a hash of index information.  Keys are index names, values are subhashes with the keys :columns and :unique :
 
   DB.indexes(:table1) # {:index1=>{:columns=>[:column1], :unique=>false}, :index2=>{:columns=>[:column2, :column3], :unique=>true}}
 

data/doc/release_notes/3.23.0.txt

@@ -11,7 +11,7 @@
   And you only want to eagerly load albums where the id is greater
   than or equal to some number provided by the user, you do:
 
-    min = params[:min]
+    min = params[:min].to_i
     Artist.eager(:albums=>proc{|ds| ds.where{id > min}})
     
   This also works when eager loading via eager_graph:

data/doc/release_notes/3.24.0.txt

@@ -0,0 +1,420 @@
+= Prepared Statement Plugins
+
+* The prepared_statements plugin makes Sequel::Model classes use
+  prepared statements for creating, updating, and destroying model
+  instances, as well as looking up model objects by primary key.
+  With this plugin, all of the following will use prepared
+  statements:
+  
+    Artist.plugin :prepared_statements
+    Artist.create(:name=>'Foo')
+    a = Artist[1]
+    a.update(:name=>'Bar')
+    a.destroy
+
+* The prepared_statements_safe plugin reduces the number of
+  prepared statements that can be created by doing two things. First,
+  it makes the INSERT statements used when creating instances to use
+  as many columns as possible, setting specific values for all
+  columns with parseable default values.  Second, it changes
+  save_changes to just use save, saving all columns instead of just
+  the changed ones.
+
+  The reason for this plugin is that Sequel's default behavior of
+  using only the values specifically set when creating instances
+  and having update only set changed columns by default can lead
+  to a large number of prepared statements being created.
+  
+  For prepared statements to be used, each set of columns in the
+  insert and update statements needs to have its own prepared
+  statement.  If you have a table with 1 primary key column and
+  4 other columns, you can have up to 2^4 = 16 prepared statements
+  created, one for each subset of the 4 columns.  If you have 1
+  primary key column and 20 other columns, there are over a million
+  subsets, and you could hit your database limit for prepared
+  statements (a denial of service attack).
+  
+  Using the prepared_statements_safe plugin mitigates this
+  issue by reducing the number of columns that may or may not be
+  present in the query, in many cases making sure that each model
+  will only have a single INSERT and a single UPDATE prepared
+  statement.
+
+* The prepared_statements_associations plugin allows normal
+  association method calls to use prepared statements if possible.
+  For example:
+  
+    Artist.plugin :prepared_statements_associations
+    Artist.many_to_one :albums
+    Artist[1].albums
+  
+  Will use a prepared statement to return the albums for that artist.
+  This plugin works for all supported association types.  There are
+  some associations (filtered and custom associations) that Sequel
+  cannot currently use a prepared statement reliably, for those
+  Sequel will use a regular query.
+
+* The prepared_statements_with_pk plugin allows the new
+  Dataset#with_pk method (explained below) to use prepared statements.
+  For example:
+  
+    Artist.plugin :prepared_statements_with_pk
+    Artist.filter(...).with_pk(1)
+  
+  Will use a prepared statement for this query.  The most benefit
+  from prepared statements come from queries that are expensive to
+  parse and plan but quick to execute, so using this plugin with
+  a complex filter can in certain cases yield significant performance
+  improvements.
+    
+  However, this plugin should be considered unsafe as it is possible
+  that it will create an unbounded number of prepared statements. It
+  extracts parameters from the dataset using Dataset#unbind
+  (explained below), so if your code has conditions that vary per
+  query but that Dataset#unbind does not handle, an unbounded number
+  of prepared statements can be created.  For example:
+  
+    Artist.filter(:a=>params[:b].to_i).with_pk[1]
+    Artist.exclude{a > params[:b].to_i}.with_pk[1]
+    
+  are safe, but:
+  
+    Artist.filter(:a=>[1, params[:b].to_i]).with_pk[1]
+    Artist.exclude{a > params[:b].to_i + 2}.with_pk[1]
+    
+  are not.  For queries that are not safe, Dataset#with_pk should
+  not be used with this plugin, you should switch to looking up by
+  primary key manually (for a regular query):
+  
+    Artist.filter(:a=>[1, params[:b].to_i])[:id=>1]
+  
+  or using the prepared statement API to create a custom prepared
+  statement:
+  
+    # PS = {}
+    PS[:name] ||= Artist.filter(:a=>[1, :$b], :id=>:$id).
+           prepare(:select, :name)
+    PS[:name].call(:b=>params[:b].to_i, :id=>1)
+    
+= Other New Features
+
+* Filtering by associations got a lot more powerful.  Sequel 3.23.0
+  introduced filtering by associations:
+  
+    Album.filter(:artist=>artist)
+    
+  This capability is much expanded in 3.24.0, allowing you to
+  exclude by associations:
+  
+    Album.exclude(:artist=>artist)
+    
+  This will match all albums not by that artist.
+    
+  You can also filter or exclude by multiple associated objects:
+  
+    Album.filter(:artist=>[artist1, artist2])
+    Album.exclude(:artist=>[artist1, artist2])
+    
+  The filtered dataset will match all albums by either of those
+  two artists, and the excluded dataset will match all albums not
+  by either of those two artists.
+  
+  You can also filter or exclude by using a model dataset:
+  
+    Album.filter(:artist=>Artist.filter(:name.like('A%'))).all
+    Album.exclude(:artist=>Artist.filter(:name.like('A%'))).all
+    
+  Here the filtered dataset will match all albums where the
+  associated artist has a name that begins with A, and the excluded
+  dataset will match all albums where the associated artist does not
+  have a name that begins with A.
+  
+  All of these types of filtering and excluding work with all of
+  association types that ship with Sequel, even the many_through_many
+  plugin.
+
+* Sequel now supports around hooks, which wrap the related before
+  hook, behavior, and after hook.  Like other Sequel hooks, these
+  are implemented as instance methods.  For example, if you wanted
+  to log DatabaseErrors raised during save:
+
+    class Artist < Sequel::Model
+      def around_save
+        super
+      rescue Sequel::DatabaseError => e
+        # log the error
+        raise
+      end
+    end
+    
+  All around hooks should call super, not yield.  If an around hook
+  doesn't call super or yield, it is treated as a hook failure,
+  similar to before hooks returning false.
+  
+  For around_validation, the return value of super should be whether
+  the object is valid.  For other around hooks, the return value of
+  super is currently true, but it's possible that will change in the
+  future.
+  
+* Dataset#with_pk has been added to model datasets that allows you
+  to find the object with the matching primary key:
+  
+    Artist.filter(:name.like('A%')).with_pk(1)
+    
+  This should make easier the common case where you want to find
+  a particular object that is associated to another object:
+  
+    Artist[1].albums_dataset.with_pk(2)
+
+  Before, there was no way to do that without manually specifying
+  the primary key:
+  
+    Artist[1].albums_dataset[:id=>2]
+    
+  To use a composite primary key with with_pk, you have to provide
+  an array:
+  
+    Artist[1].albums_dataset.with_pk([1, 2])
+    
+* Dataset#[] for model datasets will now call with_pk if given a
+  single Integer argument.  This makes the above case even easier:
+  
+    Artist[1].albums_dataset[2]
+    
+  Note that for backwards compatibility, this only works for
+  single integer primary keys.  If you have a composite primary key
+  or a string/varchar primary key, you have to use with_pk.
+
+* Dataset#unbind has been added, which allows you to take a dataset
+  that uses static bound values and convert them to placeholders.
+  Currently, the only cases handled are SQL::ComplexExpression
+  objects that use a =, !=, <, >, <=, or >= operator where the first
+  argument is a Symbol, SQL::Indentifier, or
+  SQL::QualifiedIdentifier, and the second argument is a Numeric,
+  String, Date, or Time.  Dataset#unbind returns a two element array,
+  where the first element is a modified copy of the receiver, and the
+  second element is a bound variable hash:
+  
+    ds, bv = DB[:table].filter(:a=>1).unbind
+    ds # DB[:table].filter(:a=>:$a)
+    bv # {:a=>1}
+
+  The purpose of doing this is that you can then use prepare or call
+  on the returned dataset with the returned bound variables:
+  
+    ds.call(:select, bv)
+    # SELECT * FROM table WHERE (a = ?); [1]
+    
+    ps = ds.prepare(:select, :ps_name)
+    # PREPARE ps_name AS SELECT * FROM table WHERE (a = ?)
+    ps.call(bv)
+    # EXECUTE ps_name(1)
+    
+  Basically, Dataset#unbind takes a specific statement and attempts
+  to turn it into a generic statement, along with the placeholder
+  values it extracted.
+  
+  Unfortunately, Dataset#unbind cannot handle all cases.  For
+  example:
+  
+    DB[:table].filter{a + 1 > 10}.unbind
+    
+  will not unbind any values.  Also, if you have a query with
+  multiple different values for a variable, it will raise an
+  UnbindDuplicate exception:
+  
+    DB[:table].filter(:a=>1).or(:a=>2).unbind
+
+* A defaults_setter plugin has been added that makes it easy to
+  automatically set default values when creating new objects.  This
+  plugin makes Sequel::Model behave more like ActiveRecord in that
+  new model instances (before saving) will have default values
+  parsed from the database.  Unlike ActiveRecord, only values with
+  non-NULL defaults are set.  Also, Sequel allows you to easily
+  modify the default values used:
+  
+    Album.plugin :default_values
+    Album.new.values # {:copies_sold => 0}
+    Album.default_values[:copies_sold] = 42
+    Album.new.values # {:copies_sold => 42}
+    
+  Before, this was commonly done in an after_initialize hook, but
+  that's slower as it is also called for model instances loaded from
+  the database.
+  
+* A Database#views method has been added that returns an array
+  of symbols representing view names in the database.  This works
+  just like Database#tables except it returns views.
+
+* A Sequel::ASTTransformer class was added that makes it easy to
+  write custom transformers of Sequel's internal abstract syntax
+  trees.  Dataset#qualify now uses a subclass of ASTTransformer to do
+  its transformations, as does the new Dataset#unbind.
+
+= Other Improvements
+
+* Database#create_table? now uses a single query with IF NOT EXISTS
+  if the database supports such syntax.  Previously, it issued a
+  SELECT query to determine table existence.  Sequel currently
+  supports this syntax on MySQL, H2, and SQLite 3.3.0+.
+  
+  The Database#supports_create_table_if_not_exists? method was added
+  to allow users to determine whether this syntax is supported.
+
+* Multiple column IN/NOT IN emulation now works correctly with
+  model datasets (or other datasets that use a row_proc).
+  
+* You can now correctly invert SQL::Constant instances:
+
+    Sequel::NULL # NULL
+    ~Sequel::NULL # NOT NULL
+    Sequel::TRUE # TRUE
+    ~Sequel::TRUE # FALSE
+
+* A bug in the association_pks plugin has been fixed in the case
+  where the associated table had a different primary key column name
+  than the current table.
+
+* The emulated prepared statement support now supports nil and false
+  as bound values.
+  
+* The to_dot extension was refactored for greater readability.  The
+  only change was a small fix in the display for SQL::Subscript
+  instances.
+
+* The Dataset#supports_insert_select? method is now available to let
+  you know if the dataset supports insert_select.  You should use
+  this method instead of respond_to? for checking for insert_select
+  support.
+  
+* Prepared statements/bound variable can now use a new :insert_select
+  type for preparing a statement that will insert a row and return
+  the row inserted, if the dataset supports insert_select.
+  
+* The Model#initialize_set private method now exists for easier plugin
+  writing.  It is only called for new model objects, with the hash
+  given to initialize.  By default, it just calls set.
+  
+* A small bug when creating anonymous subclasses of Sequel::Model on
+  ruby 1.9 has been fixed.
+  
+* If Thread#kill is used inside a transaction on ruby 1.8 or
+  rubinius, the transaction is rolled back.  This situation is not
+  handled correctly on JRuby or ruby 1.9, and I'm not sure it's
+  possible to handle correctly on those implementations.
+  
+* The postgres adapter now supports the
+  Sequel::Postgres::PG_NAMED_TYPES hash for associating conversion
+  procs for custom types that don't necessarily have the same type
+  oid on different databases.  This hash uses symbol keys and
+  proc values:
+  
+    Sequel::Postgres::PG_NAMED_TYPES[:interval] = proc{|v| ...}
+    
+  The conversion procs now use a separate hash per Database object
+  instead of a hash shared across all Database objects.  You
+  can now modify the types for a particular Database object, but
+  you have to use the type oid:
+  
+    DB.conversion_procs[42] = proc{|v| ...}
+
+* On SQLite and MSSQL, literalization of true and false values given
+  directly to Dataset#filter has been fixed.  So the following now
+  works correctly on those databases:
+  
+    DB[:table].filter(true)
+    DB[:table].filter(false)
+    
+  Unfortunately, because SQLite and MSSQL don't have a real boolean
+  type, these will not work:
+  
+    DB[:table].filter{a & true}
+    DB[:table].filter{a & false}
+    
+  You currently have to work around the issue by doing:
+  
+    DB[:table].filter{a & Sequel::TRUE}
+    DB[:table].filter{a & Sequel::FALSE}
+    
+  It is possible that a future version of Sequel will remove the need
+  for this workaround, but that requires having a separate
+  literalization method specific to filters.
+
+* The MySQL bit type is no longer treated as a boolean.  On MySQL, the
+  bit type is a bitfield, which is very different than the MSSQL bit
+  type, which is the closest thing to a boolean on MSSQL.
+  
+* The bool database type is now recognized as a boolean.  Some SQLite
+  databases use bool, such as the ones used in Firefox.
+  
+* SQL_AUTO_IS_NULL=0 is now set by default when connecting to MySQL
+  using the swift or jdbc adapters.  Previously, it was only set by
+  default when using the mysql or mysql2 adapters.
+
+* Dataset#limit now works correctly on Access, using the TOP syntax.
+
+* Dataset#limit now works correctly on DB2, using the FETCH FIRST
+  syntax.
+    
+* The jdbc mssql subadapter was split into separate subadapters for
+  sqlserver (using Microsoft's driver) and jtds (using the open
+  source JTDS driver).
+
+* The jdbc jtds subadapter now supports converting Java CLOB
+  objects to ruby strings.
+
+* Tables from the INFORMATION_SCHEMA are now ignored when parsing
+  schema on JDBC.
+
+* The informix adapter has been split into shared/specific parts, and
+  a jdbc informix subadapter has been added.
+
+* Dataset#insert_select now works correctly on MSSQL when the core
+  extensions are disabled.
+
+* The sqlite adapter now logs when preparing a statement.
+
+* You no longer need to be a PostgreSQL superuser to run the postgres
+  adapter specs.
+  
+* The connection pool specs are now about 10 times faster and not
+  subject to race conditions due to using Queues instead of
+  sleeping.
+
+= Backwards Compatibility
+
+* Model#save no longer calls Model#valid?.  It now calls the
+  Model#_valid? private method that Model#valid? also calls.  To mark
+  a model instance invalid, you should override the Model#validate
+  method and add validation errors to the object.
+
+* The BeforeHookFailure exception class has been renamed to
+  HookFailure since hook failures can now be raised by around hooks
+  that don't call super.  BeforeHookFailure is now an alias to
+  HookFailure, so no code should break, but you should update your
+  code to reflect the new name.
+
+* Any custom argument mappers used for prepared statements now need
+  to implement the prepared_arg? private instance method and have it
+  return true.
+
+* If your databases uses bit as a boolean type and isn't MSSQL, it's
+  possible that those columns will no longer be treated as booleans.
+  Please report such an issue on the bugtracker.
+  
+* It is possible that the filtering and excluding by association
+  datasets will break backwards compatibility in some apps.  This can
+  only occur if you are using a symbol with the same name as an
+  association with a model dataset whose model is the same as the
+  associated class.  As associations almost never have the same names
+  as columns, this would require either aliasing or joining to
+  another table.  If for some reason this does break your app, you
+  can work around it by changing the symbol to an SQL::Identifier or
+  a literal string.
+
+* The Sequel::Postgres.use_iso_date_format= method now only affects
+  future Database objects.
+
+* On MySQL, Database#tables no longer returns view names, it only
+  returns table names.  You have to use Database#views to get view
+  names now.