sequel 3.45.0 → 3.46.0

checksums.yaml

@@ -0,0 +1,7 @@
+---
+SHA1:
+  metadata.gz: f41a65970b01417999c117602accf3a2eb0acb64
+  data.tar.gz: 70f3a0b14da5779276cea3fc752b06d69b95fdee
+SHA512:
+  metadata.gz: ac4bbb6968ce5890ec6e3ba61cafc982d5508fc7aa4cab016f15fb67a237145f7461b82ad2aa6bb1cd5f90bb5327d8c616823a61fccc0d40457886cdccd3dfb6
+  data.tar.gz: f3c47bbc24033387b7cc225c58f73646bf19a477f69963f053eace7e8d8fb02b97fc78043a42d5a9d23d49b7ff1d1363de37fdeef396d177925f6f30face34b4

data/CHANGELOG

@@ -1,3 +1,37 @@
+=== 3.46.0 (2013-04-02)
+
+* Add Dataset#cross_apply and Dataset#outer_apply on Microsoft SQL Server (jeremyevans)
+
+* Speed up threaded connection pools when :connection_handling=>:queue is used (jeremyevans)
+
+* Allow external connection pool classes to be loaded automatically (jeremyevans)
+
+* Add Dataset#with_pk! for model datasets, like #with_pk, but raising instead of returning nil (jeremyevans)
+
+* Add Dataset#first!, like #first, but raising a Sequel::NoMatchingRow exception instead of returning nil (jeremyevans)
+
+* Dataset #select_map, #select_order_map, and #get no longer support a plain string inside an array of arguments (jeremyevans)
+
+* Escape ] characters in identifiers on Microsoft SQL Server (jeremyevans)
+
+* Add security guide (jeremyevans)
+
+* Make validates_type handle false values correctly (jeremyevans) (#636)
+
+* Have associations, composition, serialization, and dirty plugins clear caches in some additional cases (jeremyevans) (#635)
+
+* Add alter_table drop_foreign_key method for dropping foreign keys by column names (raxoft, jeremyevans) (#627)
+
+* Allow creation named column constraints via :*_constraint_name column options (jeremyevans)
+
+* Handle drop_constraint :type=>:primary_key on H2 (jeremyevans)
+
+* Handle infinite dates in the postgres adapter using Database#convert_infinite_timestamps (jeremyevans)
+
+* Make the looser_typecasting extension use looser typecasting for decimal columns as well as integers and floats (jeremyevans)
+
+* Do strict typecasting of decimal columns by default, similar to integer/float typecasting (jeremyevans)
+
 === 3.45.0 (2013-03-01)
 
 * Remove bad model typecasting of money type on PostgreSQL (jeremyevans) (#624)

data/README.rdoc

@@ -244,6 +244,12 @@ After filtering, you can retrieve the matching records by using any of the retri
   
 See the {Dataset Filtering}[link:files/doc/dataset_filtering_rdoc.html] file for more details.
 
+=== Security
+
+Designing apps with security in mind is a best practice.
+Please read the {Security Guide}[link:files/doc/security_rdoc.html] for details on security
+issues that you should be aware of when using Sequel.
+
 === Summarizing Records
 
 Counting records is easy using +count+:

data/Rakefile

@@ -11,25 +11,24 @@ SUDO = ENV['SUDO'] || 'sudo'
 
 # Gem Packaging and Release
 
-desc "Packages sequel"
+desc "Build sequel gem"
 task :package=>[:clean] do |p|
-  load './sequel.gemspec'
-  Gem::Builder.new(SEQUEL_GEMSPEC).build
+  sh %{#{FileUtils::RUBY} -S gem build sequel.gemspec}
 end
 
 desc "Install sequel gem"
 task :install=>[:package] do
-  sh %{#{SUDO} gem install ./#{NAME}-#{VERS.call} --local}
+  sh %{#{SUDO} #{FileUtils::RUBY} -S gem install ./#{NAME}-#{VERS.call} --local}
 end
 
 desc "Uninstall sequel gem"
 task :uninstall=>[:clean] do
-  sh %{#{SUDO} gem uninstall #{NAME}}
+  sh %{#{SUDO} #{FileUtils::RUBY} -S gem uninstall #{NAME}}
 end
 
-desc "Upload sequel gem to gemcutter"
+desc "Publish sequel gem to rubygems.org"
 task :release=>[:package] do
-  sh %{gem push ./#{NAME}-#{VERS.call}.gem}
+  sh %{#{FileUtils::RUBY} -S gem push ./#{NAME}-#{VERS.call}.gem}
 end
 
 ### Website
@@ -46,11 +45,23 @@ end
 
 ### RDoc
 
-RDOC_DEFAULT_OPTS = ["--quiet", "--line-numbers", "--inline-source", '--title', 'Sequel: The Database Toolkit for Ruby']
+RDOC_DEFAULT_OPTS = ["--line-numbers", "--inline-source", '--title', 'Sequel: The Database Toolkit for Ruby']
+
+allow_website_rdoc = begin
+  # Sequel uses hanna-nouveau for the website RDoc.
+  # Due to bugs in older versions of RDoc, and the
+  # fact that hanna-nouveau does not support RDoc 4,
+  # a specific version of rdoc is required.
+  gem 'rdoc', '= 3.12.2'
+  gem 'hanna-nouveau'
+  RDOC_DEFAULT_OPTS.concat(['-f', 'hanna'])
+  true
+rescue Gem::LoadError
+  false
+end
 
 rdoc_task_class = begin
   require "rdoc/task"
-  RDOC_DEFAULT_OPTS.concat(['-f', 'hanna'])
   RDoc::Task
 rescue LoadError
   begin
@@ -67,32 +78,34 @@ if rdoc_task_class
     rdoc.rdoc_dir = "rdoc"
     rdoc.options += RDOC_OPTS
     rdoc.rdoc_files.add %w"README.rdoc CHANGELOG MIT-LICENSE lib/**/*.rb doc/*.rdoc doc/release_notes/*.txt"
-  end if rdoc_task_class
-
-  desc "Make rdoc for website"
-  task :website_rdoc=>[:website_rdoc_main, :website_rdoc_adapters, :website_rdoc_plugins]
-
-  rdoc_task_class.new(:website_rdoc_main) do |rdoc|
-    rdoc.rdoc_dir = "www/public/rdoc"
-    rdoc.options += RDOC_OPTS
-    rdoc.rdoc_files.add %w"README.rdoc CHANGELOG MIT-LICENSE lib/*.rb lib/sequel/*.rb lib/sequel/{connection_pool,dataset,database,model}/*.rb doc/*.rdoc doc/release_notes/*.txt lib/sequel/extensions/migration.rb"
   end
 
-  rdoc_task_class.new(:website_rdoc_adapters) do |rdoc|
-    rdoc.rdoc_dir = "www/public/rdoc-adapters"
-    rdoc.options += RDOC_DEFAULT_OPTS + %w'--main Sequel'
-    rdoc.rdoc_files.add %w"lib/sequel/adapters/**/*.rb"
-  end
-
-  rdoc_task_class.new(:website_rdoc_plugins) do |rdoc|
-    rdoc.rdoc_dir = "www/public/rdoc-plugins"
-    rdoc.options += RDOC_DEFAULT_OPTS + %w'--main Sequel'
-    rdoc.rdoc_files.add %w"lib/sequel/{extensions,plugins}/**/*.rb"
-  end
-
-  desc "Update sequel.rubyforge.org"
-  task :website_rf=>[:website, :website_rdoc] do
-    sh %{rsync -rvt www/public/* rubyforge.org:/var/www/gforge-projects/sequel/}
+  if allow_website_rdoc
+    desc "Make rdoc for website"
+    task :website_rdoc=>[:website_rdoc_main, :website_rdoc_adapters, :website_rdoc_plugins]
+  
+    rdoc_task_class.new(:website_rdoc_main) do |rdoc|
+      rdoc.rdoc_dir = "www/public/rdoc"
+      rdoc.options += RDOC_OPTS + %w'--no-ignore-invalid'
+      rdoc.rdoc_files.add %w"README.rdoc CHANGELOG MIT-LICENSE lib/*.rb lib/sequel/*.rb lib/sequel/{connection_pool,dataset,database,model}/*.rb doc/*.rdoc doc/release_notes/*.txt lib/sequel/extensions/migration.rb lib/sequel/extensions/core_extensions.rb"
+    end
+  
+    rdoc_task_class.new(:website_rdoc_adapters) do |rdoc|
+      rdoc.rdoc_dir = "www/public/rdoc-adapters"
+      rdoc.options += RDOC_DEFAULT_OPTS + %w'--main Sequel --no-ignore-invalid'
+      rdoc.rdoc_files.add %w"lib/sequel/adapters/**/*.rb"
+    end
+  
+    rdoc_task_class.new(:website_rdoc_plugins) do |rdoc|
+      rdoc.rdoc_dir = "www/public/rdoc-plugins"
+      rdoc.options += RDOC_DEFAULT_OPTS + %w'--main Sequel --no-ignore-invalid'
+      rdoc.rdoc_files.add %w"lib/sequel/{extensions,plugins}/**/*.rb"
+    end
+  
+    desc "Update sequel.rubyforge.org"
+    task :website_rf=>[:website, :website_rdoc] do
+      sh %{rsync -rvt www/public/* rubyforge.org:/var/www/gforge-projects/sequel/}
+    end
   end
 end
 

data/doc/release_notes/3.46.0.txt

@@ -0,0 +1,122 @@
+= New Features
+ 
+* Dataset#first! has been added.  This is identical to #first,
+  except where #first would return nil due to no row matching,
+  #first! raises a Sequel::NoMatchingRow exception.  The main
+  benefit here is that a standard exception class is now used,
+  so external libraries can deal with these exceptions appropriately
+  (such as web applications returning a 404 error).
+
+* Dataset#with_pk! has been added to model datasets.  Similar to
+  #first!, this raises a Sequel::NoMatchingRow exception instead of
+  returning nil if there is no matching row.
+
+* A drop_foreign_key method has been added to the alter_table
+  generator:
+
+    alter_table(:tab){drop_foreign_key :col}
+
+  This relies on foreign_key_list working and including the name
+  of the foreign key.  Previously, you'd have to drop the foreign key
+  constraint before dropping the column in some cases.
+
+* Column constraints can now be named using :*_constraint_name
+  options:
+
+    create_table(:tab) do
+      primary_key :id, :primary_key_constraint_name=>:pk_name
+      foriegn_key :t_id, :t, :foreign_key_constraint_name=>:fk_name,
+        :unique=>true, :unique_constraint_name=>:uk_name
+    end
+
+  This makes it easier to name constraints, which has always been
+  recommended as it makes it easier to drop such constraints in the
+  future.
+
+* On Microsoft SQL Server, Dataset#cross_apply and #outer_apply have
+  been added to use CROSS/OUTER APPLY.  These are useful if you
+  want to join a table to the output of a function that takes the
+  table as an argument.
+
+= Other Improvements
+
+* The connection pools are now faster when using the
+  :connection_handling=>:queue option.
+
+* External connection pool classes can now be loaded automatically by
+  the :pool_class option.
+
+* Database#each_server now raises if not given a block.  Previously,
+  it just leaked Database references.
+
+* On Microsoft SQL Server, ] characters are now escaped correctly in
+  identifiers.
+
+* On PostgreSQL, infinite dates are also handled when using
+  Database#convert_infinite_timestamps.  Previously, infinite dates
+  were incorrectly converted to 0000-01-01.
+
+* The associations, composition, serialization, and dirty plugins
+  now clear caches stored in the instance in some additional cases,
+  such as when saving model instances when the dataset supports
+  insert_select.
+
+* Model#validates_type in the validation_helpers plugin now handles
+  false values correctly.
+
+* The string_stripper plugin has been fixed to not change the result
+  of Model.set_dataset.
+
+* You can now drop primary key constraints on H2, using:
+
+    alter_table(:tab){drop_constraint :foo, :type=>:primary_key}
+
+* The jdbc/as400 adapter has been fixed, it was broken starting in
+  Sequel 3.44.0.
+
+* A Security guide has been added explaining various security issues
+  to think about when using Sequel.
+
+= Backwards Compatibility
+
+* The change to make associations, composition, serialization, and
+  dirty now clear caches after saving when the dataset supports
+  insert_select can break code that expected the previous behavior.
+  For example:
+
+    artist = Artist[1]
+    artist.has_albums # => false
+
+    album = Album.new(:artist=>artist)
+    def album.after_create
+      super
+      artist.update(:has_albums=>true)
+    end
+    album.save
+
+    artist.has_albums # => false
+
+  Such code should either refresh the artist after saving the album,
+  or use album.artist.has_albums.  You already had to do that if
+  the dataset did not support insert_select; the impetus for this
+  change was to make the behavior consistent.
+
+* Decimal/numeric columns are now strictly typecast by default,
+  similar to integer and real/double precision columns.  If you want
+  the previous loose typecasting to for decimal/numeric columns,
+  use the looser_typecasting extension.
+
+* External adapters that called Database.set_adapter_scheme with a
+  string should change to using a symbol.
+
+* Dataset#select_map, #select_order_map, and #get now raise an
+  exception if they are passed a plain string inside an array.  
+  If you do want to use a plain string, you now need to alias it:
+  
+    dataset.get([Sequel.as('string', :some_alias)])
+
+= Sequel 4 Implementation Planning
+
+* Sequel 4 implementation planning has begun.  If you want to view
+  and/or provide feedback on the implementation plan, see
+  https://github.com/jeremyevans/sequel-4-plans

data/doc/schema_modification.rdoc

@@ -85,8 +85,12 @@ method, the fourth argument is the options hash.  The following options are supp
 :null :: Mark the column as allowing NULL values (if true),
          or not allowing NULL values (if false).  If unspecified, will default
          to whatever the database default is.
+:primary_key :: Mark this column as the primary key.  This is used instead of the
+                primary key method if you want a non-autoincrementing primary key.
+:primary_key_constraint_name :: The name to give the primary key constraint.
 :unique :: Mark the column as unique, generally has the same effect as
            creating a unique index on the column.
+:unique_constraint_name :: The name to give the unique key constraint.
 
 === Other methods
 
@@ -110,12 +114,13 @@ method:
   create_table(:a2){String :name, :primary_key=>true} # varchar(255) primary key
 
 If you want to create a composite primary key, you should call the +primary_key+ method with an
-array of column symbols:
+array of column symbols.  You can provide a specific name to use for the primary key constraint
+via the :name option:
 
   create_table(:items) do
     Integer :group_id
     Integer :position
-    primary_key [:group_id, :position]
+    primary_key [:group_id, :position], :name=>:items_pk
   end 
 
 If provided with an array, +primary_key+ does not create a column, it just sets up the primary key constraint.
@@ -136,6 +141,7 @@ as it's third argument.  A simple example is:
 
 :deferrable :: Makes the foreign key constraint checks deferrable, so they aren't checked
                until the end of the transaction.
+:foreign_key_constraint_name :: The name to give the foreign key constraint.
 :key :: For foreign key columns, the column in the associated table
         that this column references.  Unnecessary if this column
         references the primary key of the associated table, at least
@@ -271,7 +277,7 @@ to <tt>Dataset#where</tt>:
 ==== +check+
 
 +check+ operates just like +constraint+, except that it doesn't take a name
-and it creates an unnamed constraint
+and it creates an unnamed constraint:
 
   create_table(:artists) do
     primary_key :id
@@ -279,6 +285,9 @@ and it creates an unnamed constraint
     check{char_length(name) > 2}
   end
   
+It's recommended that you use the +constraint+ method and provide a name for the
+constraint, as that makes it easier to drop the constraint later if necessary.
+
 == +create_join_table+
 
 +create_join_table+ is a shortcut that you can use to create simple many-to-many join tables:
@@ -371,19 +380,46 @@ creates a new column:
   end
 
 If you want to add a new foreign key constraint to an existing column, you provide an
-array with a single element:
+array with a single element.  It's encouraged to provide a name when adding the constraint,
+via the :name option:
 
   alter_table(:albums) do
-    add_foreign_key [:artist_id], :artists
+    add_foreign_key [:artist_id], :artists, :name=>:albums_artist_id_fkey
   end
 
 To set up a multiple column foreign key constraint, use an array with multiple column
 symbols:
 
   alter_table(:albums) do
-    add_foreign_key [:artist_name, :artist_location], :artists
+    add_foreign_key [:artist_name, :artist_location], :artists, :name=>:albums_artist_name_location_fkey
+  end
+
+=== +drop_foreign_key+
+
++drop_foreign_key+ is used to drop foreign keys from tables.  If you provide a symbol as
+the first argument, it drops both the foreign key constraint and the column:
+
+  alter_table(:albums) do
+    drop_foreign_key :artist_id
   end
 
+If you want to just drop the foreign key constraint without dropping the column, use
+an array.  It's encouraged to use the :name option to provide the constraint name to
+drop, though on some databases Sequel may be able to find the name through introspection:
+
+  alter_table(:albums) do
+    drop_foreign_key [:artist_id], :name=>:albums_artist_id_fkey
+  end
+
+An array is also used to drop a composite foreign key constraint:
+
+  alter_table(:albums) do
+    drop_foreign_key [:artist_name, :artist_location], :name=>:albums_artist_name_location_fkey
+  end
+
+If you do not provide a :name option and Sequel is not able to determine the name
+to use, it will probably raise a Sequel::Error exception.
+
 === +add_index+
 
 +add_index+ works just like +create_table+'s +index+ method, creating a new index on

data/doc/security.rdoc

@@ -0,0 +1,379 @@
+= Security Considerations with Sequel
+
+When using Sequel, there are some security areas you should be aware of:
+
+* Code Execution
+* SQL Injection
+* Denial of Service
+* Mass Assignment
+* General Parameter Handling
+
+== Code Execution
+
+The most serious security vulnerability you can have in any library is
+a code execution vulnerability.  Sequel should not be vulnerable to this,
+as it never calls eval on a string that is derived from user input.
+However, some Sequel methods used for creating methods via metaprogramming
+could conceivably be abused to do so:
+
+* Sequel::Schema::CreateTableGenerator.add_type_method
+* Sequel::Dataset.def_mutation_method
+* Sequel::Dataset.def_append_methods
+* Sequel.def_adapter_method (private)
+* Sequel::Model::InstanceMethods.class_attr_overridable (private)
+* Sequel::Model::InstanceMethods.class_attr_reader (private)
+* Sequel::SQL::Expression.to_s_method (private)
+* Sequel::Plugins::HookClassMethods::ClassMethods#add_hook_type
+
+As long as you don't call those with user input, you should not be
+vulnerable to code execution.
+
+== SQL Injection
+
+The primary security concern in SQL database libraries is SQL injection.
+Because Sequel mostly promotes using ruby objects for SQL concepts instead
+of raw SQL, it is less likely to be vulnerable to SQL injection.
+However, because Sequel still makes it easy to use raw SQL, misuse of the
+library can result in SQL injection in your application.
+
+There are basically two kinds of possible SQL injections in Sequel:
+
+* SQL code injections
+* SQL identifier injections
+
+=== SQL Code Injections
+
+==== Full SQL Strings
+
+Some Sequel methods are designed to execute raw SQL, including:
+
+* Sequel::Database#execute
+* Sequel::Database#run
+* Sequel::Database#<<
+* Sequel::Database#[]
+* Sequel::Database#fetch
+* Sequel::Dataset#with_sql
+
+Here are some examples of use:
+
+  DB.run 'SQL'
+  DB << 'SQL'
+  DB.execute 'SQL'
+  DB['SQL'].all
+  DB.fetch('SQL').all
+  DB.dataset.with_sql('SQL').all
+
+If you pass a string to these methods that is derived from user input, you open
+yourself up to SQL injection.  The Sequel::Database#run, Sequel::Database#<<, and
+Sequel::Database#execute methods are not designed to work at all with user input.
+If you must use them with user input, you should escape the user input manually
+via Sequel::Database#literal. Example:
+
+  DB.run "SOME SQL #{DB.literal(params[:user].to_s)}"
+
+With Sequel::Database#[], Sequel::Database#fetch and Sequel::Dataset#with_sql, you should use placeholders,
+in which case Sequel automatically literalizes the input:
+
+  DB['SELECT * FROM foo WHERE bar = ?', params[:user].to_s]
+
+==== Manually Created Literal Strings
+
+Sequel generally treats ruby strings as SQL strings (escaping them correctly), and
+not as raw SQL.  However, you can convert a ruby string to a literal string, and
+Sequel will then treat it as raw SQL.  This is typically done through String#lit
+if the {core_extensions}[link:files/doc/core_extensions_rdoc.html] are in use,
+or Sequel.lit[rdoc-ref:Sequel::SQL::Builders#lit] if they are not in use.
+
+  'a'.lit
+  Sequel.lit('a')
+
+Using String#lit or Sequel.lit[rdoc-ref:Sequel::SQL::Builders#lit] to turn a ruby string into a literal string results
+in SQL injection if the string is derived from user input.  With both of these
+methods, the strings can contain placeholders, which you can use to safely include
+user input inside a literal string:
+
+  'a = ?'.lit(params[:user_id].to_s)
+  Sequel.lit('a = ?', params[:user_id].to_s)
+
+Even though they have similar names, note that Sequel::Database#literal operates very differently from
+String#lit or Sequel.lit[rdoc-ref:Sequel::SQL::Builders#lit].
+Sequel::Database#literal is for taking any supported object,
+and getting an SQL representation of that object, while
+String#lit or Sequel.lit[rdoc-ref:Sequel::SQL::Builders#lit] are for treating
+a ruby string as raw SQL.  For example:
+
+  DB.literal(Date.today) # "'2013-03-22'"
+  DB.literal('a') # "'a'"
+  DB.literal(Sequel.lit('a')) # "a"
+  DB.literal(:a => 'a') # "(\"a\" = 'a')"
+  DB.literal(:a => Sequel.lit('a')) # "(\"a\" = a)"
+
+==== SQL Filter Fragments
+
+The most common way to use raw SQL with Sequel is in filters:
+
+  DB[:table].where("name > 'M'")
+
+If a filter method is passed a string as the first argument, it treats the rest of
+the arguments (if any) as placeholders to the string.  So you should never do:
+
+  DB[:table].where("name > #{params[:id].to_s}") # SQL Injection!
+
+Instead, you should use a placeholder:
+
+  DB[:table].where("name > ?", params[:id].to_s) # Safe
+ 
+Note that for that type of query, Sequel generally encourages the following form:
+
+  DB[:table].where{|o| o.name > params[:id].to_s} # Safe
+
+Sequel's DSL supports a wide variety of SQL concepts, so it's possible to
+code most applications without every using raw SQL.
+
+A large number of dataset methods ultimately pass down their arguments to a filter
+method, even some you may not expect, so you should be careful.  At least the
+following methods pass their arguments to a filter method:
+
+* Sequel::Dataset#where
+* Sequel::Dataset#having
+* Sequel::Dataset#filter
+* Sequel::Dataset#exclude
+* Sequel::Dataset#exclude_where
+* Sequel::Dataset#exclude_having
+* Sequel::Dataset#and
+* Sequel::Dataset#or
+* Sequel::Dataset#first
+* Sequel::Dataset#last
+* Sequel::Dataset#[]
+* Sequel::Dataset#[]=
+
+The Model.find[rdoc-ref:Sequel::Model::ClassMethods#find] and Model.find_or_create[rdoc-ref:Sequel::Model::ClassMethods#find_or_create]
+class methods also call down to the filter methods.
+
+==== SQL Fragment passed to Dataset#update
+
+Similar to the filter methods, Sequel::Dataset#update (and alias Sequel::Dataset#set) also treat a
+string argument as raw SQL:
+
+  DB[:table].update("column = 1")
+
+So you should not do:
+
+  DB[:table].update("column = #{params[:value].to_s}") # SQL Injection!
+
+Instead, you should do:
+
+  DB[:table].update(:column => params[:value].to_s) # Safe
+
+=== SQL Identifier Injections
+
+Usually, Sequel treats ruby symbols as SQL identifiers, and ruby
+strings as SQL strings.  However, there are some parts of Sequel
+that treat ruby strings as SQL identifiers if an SQL string would
+not make sense in the same context.
+
+For example, Sequel::Database#from and Sequel::Dataset#from will treat a string as
+a table name:
+
+  DB.from('t') # SELECT * FROM "t"
+
+Another place where Sequel treats ruby strings as identifiers are
+the Sequel::Dataset#insert and Sequel::Dataset#update methods:
+
+  DB[:t].update('b'=>1) # UPDATE "t" SET "b" = 1
+  DB[:t].insert('b'=>1) # INSERT INTO "t" ("b") VALUES (1)
+
+Note how the identifier is still quoted in these cases.  Sequel quotes identifiers by default
+on most databases.  However, it does not quote identifiers by default on DB2 and Informix.
+On those databases using an identifier derived from user input can lead to SQL injection.
+Similarly, if you turn off identifier quoting manually on other databases, you open yourself
+up to SQL injection if you use identifiers derived from user input.
+
+When Sequel quotes identifiers, using an identifier derived from user input does not lead to
+SQL injection, since the identifiers are also escaped when quoting.
+Exceptions to this are Oracle (can't escape <tt>"</tt>) and Microsoft Access
+(can't escape <tt>]</tt>).
+
+In general, even if doesn't lead to SQL Injection, you should avoid using identifiers
+derived from user input unless absolutely necessary.
+
+Sequel also allows you to create identifiers using
+Sequel.identifier[rdoc-ref:Sequel::SQL::Builders#identifier] for plain identifiers,
+Sequel.qualify[rdoc-ref:Sequel::SQL::Builders#qualify] for qualified identifiers, and
+Sequel.as[rdoc-ref:Sequel::SQL::Builders#as] for aliased expressions.  So if you
+pass any of those values derived from user input, you are dealing with the same scenario.
+
+Note that the issues with SQL identifiers do not just apply to places where
+strings are used as identifiers, they also apply to all places where Sequel
+uses symbols as identifiers.  However, if you are creating symbols from user input,
+you at least have a denial of service vulnerability, and possibly a more serious
+vulnerability.
+
+== Denial of Service
+
+Sequel converts some strings to symbols.  Because symbols in ruby are not
+garbage collected, if the strings that are converted to symbols are
+derived from user input, you have a denial of service vulnerability due to
+memory exhaustion.
+
+The strings that Sequel converts to symbols are generally not derived
+from user input, so Sequel in general is not vulnerable to this.  However,
+users should be aware of the cases in which Sequel creates symbols, so
+they do not introduce a vulnerability into their application.
+
+=== Column Names/Aliases
+
+Sequel returns SQL result sets as an array of hashes with symbol keys.  The
+keys are derived from the name that the database server gives the column. These
+names are generally static.  For example:
+
+  SELECT column FROM table
+
+The database will generally use "column" as the name in the result set.
+
+If you use an alias:
+
+  SELECT column AS alias FROM table
+
+The database will generally use "alias" as the name in the result set. So
+if you allow the user to control the alias name:
+
+  DB[:table].select(:column.as(params[:alias]))
+
+Then you have a denial of service vulnerability.  In general, such a vulnerability
+is unlikely, because you are probably indexing into the returned hash(es) by name,
+and if an alias was used and you didn't expect it, your application wouldn't work.
+
+The more insidious cases are those where an explicit alias is not used at all, but
+an unaliased expression is used and the database chooses which alias to use.  For
+example, on SQLite, the following types of queries are vulnerable to denial of service:
+
+  DB[:table].get(params[:a].to_s)
+  DB[:table].select_map(params[:b].to_s)
+  DB[:table].select_order_map(params[:c].to_s)
+
+In these cases, the queries will work correctly, but an unused symbol will be created.
+To protect against the denial of service, use an explicit alias:
+
+  DB[:table].get(Sequel.as(params[:a].to_s, :a))
+  DB[:table].select_map(Sequel.as(params[:b].to_s, :a))
+  DB[:table].select_order_map(Sequel.as(params[:c].to_s, :a))
+
+While the above code is unlikely to be used in practice, variants that use expressions
+could be.  For example, if you want to select all values in a specific column, with
+a suffix provided by the user:
+
+  DB[:table].select_map(Sequel.join(:column, params[:suffix].to_s))
+
+As above, you should use an explicit alias to protect against denial of service:
+
+  DB[:table].select_map(Sequel.join(:column, params[:suffix].to_s).as(:a))
+
+=== Database Connection Options
+
+All database connection options are converted to symbols.  For a
+connection URL, the keys are generally fixed, but the scheme is turned
+into a symbol and the query option keys are used as connection option
+keys, so they are converted to symbols as well.  For example:
+
+  postgres://host/database?option1=foo&option2=bar
+
+Will result in :postgres, :option1, and :option2 symbols being created.
+
+Certain option values are also converted to symbols.  In the general case,
+the sql_log_level option value is, but some adapters treat additional
+options similarly.
+
+This is not generally a risk unless you are allowing the user to control
+the connection URLs or are connecting to arbitrary databases at runtime.
+
+== Mass Assignment
+
+Mass assignment is the practice of passing a hash of columns and values
+to a single method, and having multiple column values for a given object set
+based on the content of the hash.
+The security issue here is that mass assignment may allow the user to
+set columns that you didn't intend to allow.
+
+The Model#set[rdoc-ref:Sequel::Model::InstanceMethods#set] and Model#update[rdoc-ref:Sequel::Model::InstanceMethods#update] methods do mass
+assignment.  The default configuration of Sequel::Model allows all model
+columns except for the primary key column(s) to be set via mass assignment.
+
+Example:
+
+  album = Album.new
+  album.set(params[:album]) # Mass Assignment
+
+Both Model.new[rdoc-ref:Sequel::Model::InstanceMethods::new] and Model.create[rdoc-ref:Sequel::Model::ClassMethods#create]
+call Model#set[rdoc-ref:Sequel::Model::InstanceMethods#set] internally, so
+they also allow mass assignment:
+
+  Album.new(params[:album]) # Mass Assignment
+  Album.create(params[:album]) # Mass Assignment
+
+Instead of these methods, it is encouraged to either use the
+Model#set_only[rdoc-ref:Sequel::Model::InstanceMethods#set_only],
+Model#update_only[rdoc-ref:Sequel::Model::InstanceMethods#update_only],
+Model#set_fields[rdoc-ref:Sequel::Model::InstanceMethods#set_fields], or
+Model#update_fields[rdoc-ref:Sequel::Model::InstanceMethods#update_fields]
+methods, which allow you to specify which fields
+to allow on a per-call basis.  This pretty much eliminates the chance that the
+user will be able to set a column you did not intend to allow:
+
+  album.set_only(params[:album], [:name, :copies_sold])
+  album.set_fields(params[:album], [:name, :copies_sold])
+
+You can override the columns to allow by default during mass assignment via
+the Model.set_allowed_columns[rdoc-ref:Sequel::Model::ClassMethods#set_allowed_columns] class method.  This is a good
+practice, though being explicit on a per-call basis is still recommended:
+
+  Album.set_allowed_columns(:name, :copies_sold)
+  Album.create(params[:album]) # Only name and copies_sold set
+
+For more details on the mass assignment methods, see the {Mass Assignment Guide}[link:files/doc/mass_assignment_rdoc.html].
+
+== General Parameter Handling
+
+This issue isn't necessarily specific to Sequel, but it is a good general practice.
+If you are using values derived from user input, it is best to be explicit about
+their type.  For example:
+
+  Album.where(:id=>params[:id])
+
+is probably a bad idea.  Assuming you are using a web framework, params\[:id\] could
+be a string, an array, a hash, or nil.
+
+Assuming that +id+ is an integer field, you probably want to do:
+
+  Album.where(:id=>params[:id].to_i)
+
+If you are looking something up by name, you should try to enforce the value to be
+a string:
+
+  Album.where(:name=>params[:name].to_s)
+
+If you are trying to use an IN clause with a list of id values based on input provided
+on a web form:
+
+  Album.where(:id=>params[:ids].to_a.map{|i| i.to_i})
+
+Basically, be as explicit as possible. While there aren't any known security issues
+in Sequel when you do:
+
+  Album.where(:id=>params[:id])
+
+It allows the attacker to choose to do any of the following queries:
+
+  id IS NULL # nil
+  id = '1' # '1'
+  id IN ('1', '2', '3') # ['1', '2', '3']
+  id = ('a' = 'b') # {'a'=>'b'}
+  id = ('a' IN ('a', 'b') AND 'c' = '') # {'a'=>['a', 'b'], 'c'=>''}
+
+While none of those allow for SQL injection, it's possible that they
+might have an issue in your application.  For example, a long array
+or deeply nested hash might cause the database to have to do a lot of
+work that could be avoided.
+
+In general, it's best to let the attacker control as little as possible,
+and explicitly specifying types helps a great deal there.