sequel 3.21.0 → 3.31.0

data/Rakefile

@@ -1,11 +1,5 @@
 require "rake"
 require "rake/clean"
-require "rake/gempackagetask"
-begin
-  require "hanna/rdoctask"
-rescue LoadError
-  require "rake/rdoctask"
-end
 
 NAME = 'sequel'
 VERS = lambda do
@@ -13,14 +7,13 @@ VERS = lambda do
   Sequel.version
 end
 CLEAN.include ["**/.*.sw?", "sequel-*.gem", ".config", "rdoc", "coverage", "www/public/*.html", "www/public/rdoc*", '**/*.rbc']
-RDOC_DEFAULT_OPTS = ["--quiet", "--line-numbers", "--inline-source", '--title', 'Sequel: The Database Toolkit for Ruby']
-RDOC_OPTS = RDOC_DEFAULT_OPTS + ['--main', 'README.rdoc']
 
 # Gem Packaging and Release
 
 desc "Packages sequel"
 task :package=>[:clean] do |p|
-  sh %{gem build sequel.gemspec}
+  load './sequel.gemspec'
+  Gem::Builder.new(SEQUEL_GEMSPEC).build
 end
 
 desc "Install sequel gem"
@@ -40,7 +33,20 @@ end
 
 ### RDoc
 
-Rake::RDocTask.new do |rdoc|
+RDOC_DEFAULT_OPTS = ["--quiet", "--line-numbers", "--inline-source", '--title', 'Sequel: The Database Toolkit for Ruby']
+
+rdoc_task_class = begin
+  require "rdoc/task"
+  RDOC_DEFAULT_OPTS.concat(['-f', 'hanna'])
+  RDoc::Task
+rescue LoadError
+  require "rake/rdoctask"
+  Rake::RDocTask
+end
+
+RDOC_OPTS = RDOC_DEFAULT_OPTS + ['--main', 'README.rdoc']
+
+rdoc_task_class.new do |rdoc|
   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"
@@ -50,25 +56,25 @@ end
 
 desc "Make local version of website"
 task :website do
-  sh %{www/make_www.rb}
+  sh %{#{FileUtils::RUBY} www/make_www.rb}
 end
 
 desc "Make rdoc for website"
 task :website_rdoc=>[:website_rdoc_main, :website_rdoc_adapters, :website_rdoc_plugins]
 
-Rake::RDocTask.new(:website_rdoc_main) do |rdoc|
+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
 
-Rake::RDocTask.new(:website_rdoc_adapters) do |rdoc|
+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
 
-Rake::RDocTask.new(:website_rdoc_plugins) do |rdoc|
+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"
@@ -92,11 +98,13 @@ begin
     require "spec/rake/spectask"
     spec_class = Spec::Rake::SpecTask
     spec_files_meth = :spec_files=
+    spec_opts_meth = :spec_opts=
   rescue LoadError
     # RSpec 2
     require "rspec/core/rake_task"
     spec_class = RSpec::Core::RakeTask
     spec_files_meth = :pattern=
+    spec_opts_meth = :rspec_opts=
   end
 
   spec = lambda do |name, files, d|
@@ -105,25 +113,35 @@ begin
     desc d
     spec_class.new(name) do |t|
       t.send spec_files_meth, files
-      t.spec_opts = ENV['SEQUEL_SPEC_OPTS'].split if ENV['SEQUEL_SPEC_OPTS']
+      t.send spec_opts_meth, ENV['SEQUEL_SPEC_OPTS'].split if ENV['SEQUEL_SPEC_OPTS']
     end
   end
 
-  spec_with_cov = lambda do |name, files, d|
+  sc = spec_with_cov = lambda do |name, files, d|
     spec.call(name, files, d)
     t = spec.call("#{name}_cov", files, "#{d} with coverage")
     t.rcov = true
     t.rcov_opts = File.read("spec/rcov.opts").split("\n")
+    t
+  end
+
+  if RUBY_VERSION >= '1.8.7'
+    eval <<-END
+      spec_with_cov = lambda do |*x, &b|
+        t = sc.call(*x)
+        b.call(t) if b
+      end
+    END
   end
   
   task :default => [:spec]
-  spec_with_cov.call("spec", Dir["spec/{core,model}/*_spec.rb"], "Run core and model specs")
+  spec_with_cov.call("spec", Dir["spec/{core,model}/*_spec.rb"], "Run core and model specs"){|t| t.rcov_opts.concat(%w'--exclude "lib/sequel/adapters/([a-ln-z]|m[a-np-z])"')}
   spec.call("spec_core", Dir["spec/core/*_spec.rb"], "Run core specs")
   spec.call("spec_model", Dir["spec/model/*_spec.rb"], "Run model specs")
   spec_with_cov.call("spec_plugin", Dir["spec/extensions/*_spec.rb"], "Run extension/plugin specs")
   spec_with_cov.call("spec_integration", Dir["spec/integration/*_test.rb"], "Run integration tests")
   
-  %w'postgres sqlite mysql informix oracle firebird mssql'.each do |adapter|
+  %w'postgres sqlite mysql informix oracle firebird mssql db2'.each do |adapter|
     spec_with_cov.call("spec_#{adapter}", ["spec/adapters/#{adapter}_spec.rb"] + Dir["spec/integration/*_test.rb"], "Run #{adapter} specs")
   end
 rescue LoadError
@@ -154,5 +172,5 @@ end
 
 desc "Check syntax of all .rb files"
 task :check_syntax do
-  Dir['**/*.rb'].each{|file| print `#{ENV['RUBY'] || :ruby} -c #{file} | fgrep -v "Syntax OK"`}
+  Dir['**/*.rb'].each{|file| print `#{FileUtils::RUBY} -c #{file} | fgrep -v "Syntax OK"`}
 end

data/bin/sequel

@@ -112,11 +112,7 @@ end
 
 connect_proc = lambda do |database|
   db = if database.nil? || database.empty?
-    db = Sequel::Database.new(:quote_identifiers=>false)
-    def db.connect(*args); Object.new; end
-    db.identifier_input_method = nil
-    db.identifier_output_method = nil
-    db
+    Sequel.connect('mock:///', db_opts)
   elsif File.exist?(database)
     require 'yaml'
     env ||= "development"

data/doc/association_basics.rdoc

@@ -247,7 +247,7 @@ example is a tree structure:
   
   class Node
     many_to_one :parent, :class=>self
-    one_to_many :children :key=>:parent_id, :class=>self
+    one_to_many :children, :key=>:parent_id, :class=>self
   end
 
 For many_to_many self_referential associations, it's fairly similar.  Here's
@@ -293,32 +293,6 @@ Examples:
   @artist.remove_album(@album)
   @artist.remove_all_albums
 
-== Dataset Method
-
-In addition to the above methods, associations also add a instance method
-ending in +_dataset+ that returns a dataset representing the objects in the associated table:
-
-  @album.artist_id
-  # 10
-  @album.artist_dataset
-  # SELECT * FROM artists WHERE (id = 10)
-  
-  @artist.id
-  # 20
-  @artist.albums_dataset
-  # SELECT * FROM albums WHERE (artist_id = 20)
-
-The association dataset is just like any other Sequel dataset, in that
-it can be further filtered, ordered, etc.:
-
-  @artist.albums_dataset.
-   filter(:name.like('A%')).
-   order(:copies_sold).
-   limit(10)
-  # SELECT * FROM albums
-  # WHERE ((artist_id = 20) AND (name LIKE 'A%'))
-  # ORDER BY copies_sold LIMIT 10
-
 == Caching
 
 Associations are cached after being retrieved:
@@ -352,13 +326,150 @@ instance method:
   @album.artists # [<Artist ...>, ...]
   @album.associations[:artists] # [<Artist ...>, ...]
 
-Note that while the association method caches associated objects, if you
-retrieve access through the association dataset directly, the results
-will not be cached:
+== Dataset Method
+
+In addition to the above methods, associations also add a instance method
+ending in +_dataset+ that returns a dataset representing the objects in the associated table:
+
+  @album.artist_id
+  # 10
+  @album.artist_dataset
+  # SELECT * FROM artists WHERE (id = 10)
+  
+  @artist.id
+  # 20
+  @artist.albums_dataset
+  # SELECT * FROM albums WHERE (artist_id = 20)
+
+The association dataset is just like any other Sequel dataset, in that
+it can be further filtered, ordered, etc.:
+
+  @artist.albums_dataset.
+   filter(:name.like('A%')).
+   order(:copies_sold).
+   limit(10)
+  # SELECT * FROM albums
+  # WHERE ((artist_id = 20) AND (name LIKE 'A%'))
+  # ORDER BY copies_sold LIMIT 10
+
+Records retrieved using the +_dataset+ method are not cached in the
+associations cache.
 
   @album.artists_dataset.all # [<Artist ...>, ...]
   @album.associations[:artists] # nil
 
+== Dynamic Association Modification
+
+Similar to the +_dataset+ method, you can provide a block to the association
+method to customize the dataset that will be used to retrieve the records.  So
+you can apply a filter in either of these two ways:
+
+  @artist.albums_dataset.filter(:name.like('A%'))
+  @artist.albums{|ds| ds.filter(:name.like('A%'))}
+
+While they both apply the same filter, using the +_dataset+ method does not
+apply any of the association callbacks or handle association reciprocals (see
+below for details about callbacks and reciprocals).  Using a block instead handles
+all those things, and also caches its results in the associations cache (ignoring
+any previously cached value).
+
+Note that if you are using ruby 1.8.6, you can't pass a block to the association
+method, you have to pass a proc as an argument:
+
+  @artist.albums(proc{|ds| ds.filter(:name.like('A%'))})
+
+== Filtering By Associations
+
+In addition to using the association method to get associated objects, you
+can also use associated objects in filters.  For example, to get
+all albums for a given artist, you would usually do:
+
+  @artist.albums
+  # or @artist.albums_dataset for a dataset
+
+You can also do the following:
+
+  Album.filter(:artist=>@artist).all
+  # or leave off the .all for a dataset
+
+For filtering by a single association, this isn't very useful.  However, unlike
+using the association method, using a filter allows you to filter by multiple
+associations:
+
+  Album.filter(:artist=>@artist, :publisher=>@publisher)
+
+This will return all albums by that artist and published by that publisher.
+This isn't possible using just the association method approach, though you
+can combine the approaches:
+
+  @artist.albums_dataset.filter(:publisher=>@publisher)
+
+This doesn't just work for +many_to_one+ associations, it also works for
++one_to_one+, +one_to_many+, and +many_to_many+ associations:
+
+  Album.one_to_one :album_info
+  # The album related to that AlbumInfo instance
+  Album.filter(:album_info=>AlbumInfo[2])
+
+  Album.one_to_many :tracks
+  # The album related to that Track instance
+  Album.filter(:tracks=>Track[3])
+
+  Album.many_to_many :tags
+  # All albums related to that Tag instance
+  Album.filter(:tags=>Tag[4])
+
+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 can also exclude by associations:
+
+  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).
+
 == Name Collisions
 
 Because associations create instance methods, it's possible to override
@@ -368,7 +479,7 @@ would be bad association names.
 
 == Database Schema
 
-Creating an association, doesn't modify the database schema.  Sequel
+Creating an association doesn't modify the database schema.  Sequel
 assumes your associations reflect the existing database schema.  If not,
 you should modify your schema before creating the associations.
 
@@ -1055,7 +1166,7 @@ when eager loading via eager_graph, but called when eager loading via eager.
   class Artist
     # Cache all album names to a single string when retrieving the
     # albums.
-    one_to_many :albums, :after_add=>:cache_album_names
+    one_to_many :albums, :after_load=>:cache_album_names
     
     attr_reader :album_names
     
@@ -1218,25 +1329,44 @@ a JOIN USING or NATURAL JOIN for the graph:
   Artist.one_to_many :albums, :key=>:artist_name,
    :graph_only_conditions=>nil, :graph_join_type=>:natural
 
+==== :graph_alias_base
+
+The base name to use for the table alias when eager graphing.  Defaults to the name
+of the association.  If the alias name has already been used in the query, Sequel will create
+a unique alias by appending a numeric suffix (e.g. alias_0, alias_1, ...) until the alias is
+unique.
+
+This is mostly useful if you have associations with the same name in many models, and you want
+to be able to easily tell which table alias corresponds to which association when eagerly
+graphing multiple associations with the same name.
+
 ==== :eager_grapher
 
 Sets up a custom grapher to use when eager loading the objects via eager_graph.
-This is the eager_graph analogue to the :eager_loader option.
+This is the eager_graph analogue to the :eager_loader option. This isn't generally
+needed, as one of the other eager_graph related association options is usually sufficient.
 
-If specified, should be a proc that accepts three three arguments: a dataset,
-an alias to use for the table to graph for this association, and the alias that
-was used for the current table (since you can cascade associations). Should
-return a modified copy of the dataset with the association graphed into it.
+If specified, should be a proc that accepts one or three three arguments.
+If the proc takes one argument, it will be given a hash with the following keys:
+
+:self :: The dataset that is doing the eager loading
+:table_alias :: An alias to use for the table to graph for this association.
+:implicit_qualifier :: The alias that was used for the current table (since you can cascade associations).
+:callback :: A callback proc used to dynamically modify the dataset to graph into the
+             current dataset, before such graphing is done. This is nil if no callback
+             proc is used.
+
+If the proc takes three arguments, it gets passed the :self, :association_alias,
+and :table_alias values. The 3 argument procs are allowed for backwards
+compatibility, and it is recommended to use the 1 argument proc format
+for new code.
 
   Artist.one_to_many :self_title_albums, :class=>:Album,
-   :eager_grapher=>(proc do |ds, ta, iq|
-    ds.graph(Album, {:artist_id=>:id, :name=>:name},
-      :table_alias=>ta, :implicit_qualifier=>iq)
+   :eager_grapher=>(proc do |eo|
+    eo[:self].graph(Album, {:artist_id=>:id, :name=>:name},
+      :table_alias=>eo[:table_alias], :implicit_qualifier=>eo[:implicit_qualifier])
   end)
 
-This isn't generally needed, as one of the other eager_graph related
-association options is usually sufficient.
-
 ==== :order_eager_graph
 
 Whether to add the order to the dataset's order when graphing via eager_graph.
@@ -1353,6 +1483,34 @@ If the default modification methods would not do what you want, and you
 don't plan on overriding the internal modification methods to do what you
 want, it may be best to set this option to true.
 
+==== :key_column [+many_to_one+]
+
+This option exists to make it possible to create a +many_to_one+ association
+with the same name as the foreign key it uses.  Before this option was
+introduced, this was problematic, since the :key option was used to refer
+both to the model methods and the underlying database columns (which are
+usually the same).
+
+If you have a legacy database with a foreign key that is the same as the name
+of the association you would like to use, you should create a column alias
+for the foreign key and use this option:
+
+  # Example schema:
+  #  albums           artists
+  #   :id        /-->  :id
+  #   :artist --/      :name
+  #   :name
+
+  class Album < Sequel::Model
+    def_column_alias(:artist_id, :artist)
+    many_to_one :artist, :key_column=>:artist
+  end
+
+Note that if you have control over the database, it's better to just rename
+the foreign key column than use this option.  Similarly, if you can think
+of another association name that will work, it's wiser to rename the
+association than use this option.  Think of this option as a last resort.
+
 ==== :validate
 
 Set to false to not validate when implicitly saving any associated object.
@@ -1399,3 +1557,51 @@ associations depends on another plugin that defines instance methods of
 the same name.  In that case, the instance methods of the dependent
 plugin would override the association methods created by the main
 plugin.
+
+==== :eager_limit_strategy
+
+This setting determines what strategy to use for loading the associations
+that use the :limit setting to limit the number of returned records. You
+can't use LIMIT directly, since you want a limit for each associated
+record, not a LIMIT on the number of records returned by the dataset.
+
+By default, no strategy is used for one_to_one associations, and
+the :ruby strategy is used for *_many associations, which does a simple
+array slice after loading the associated records.  That doesn't provide
+a performance advantage, since all records are still loaded from the
+database, but it at least makes sure the cached records are accurately
+limited as they would be in the lazy load case.
+
+The reason no strategy is used by default for one_to_one associations
+is that none is needed for a true one_to_one association (since there
+is only one associated record per current record).  However, if you are
+using a one_to_one association where the relationship is really one_to_many,
+and using an order to pick the first matching row, then if you don't
+specify an :eager_limit_strategy option, you'll be loading all related
+rows just to have Sequel ignore all rows after the first.  By using a
+strategy to change the query to only return one associated record per
+current record, you can get much better database performance.
+
+You can set a value of +true+ for this option to have Sequel select what
+it thinks is the best way of limiting the records for your database.  You
+can also specify a symbol to manually choose a strategy.  The available
+strategies are:
+
+:distinct_on :: Uses DISTINCT ON to ensure only the first matching record
+                is loaded (one_to_one associations only). This is used by
+                default on PostgreSQL.
+:window_function :: Uses window functions if the database supports it.
+                    This is used by default on databases that support window
+                    functions.
+:correlated_subquery :: Uses a correlated subquery to get the information.
+                        This is never used by default as if you aren't careful,
+                        it can result in pathologically long running times
+                        This will not work correctly for association where
+                        the associated table has a composite primary key if
+                        the database doesn't support using IN
+                        with multiple columns.  This will also not work on MySQL
+                        because MySQL has problems using IN with a correlated
+                        subquery that contains a limit.
+:ruby :: Uses ruby array slicing to emulate database limiting (*_many
+         associations only).  This is the default if the database doesn't
+         support window functions.

data/doc/dataset_basics.rdoc

@@ -74,12 +74,12 @@ Most Dataset methods that users will use can be broken down into two types:
 
 Most dataset methods fall into this category, which can be further broken down by the clause they affect:
 
-SELECT:: select, select_all, select_append, select_more
+SELECT:: select, select_all, select_append, select_group, select_more
 FROM:: from, from_self
 JOIN:: join, left_join, right_join, full_join, natural_join, natural_left_join, natural_right_join, natural_full_join, cross_join, inner_join, left_outer_join, right_outer_join, full_outer_join, join_table
-WHERE:: where, filter, exclude, and, or, grep, invert, unfiltered
-GROUP:: group, group_by, group_and_count, ungrouped
-HAVING:: having, filter, exclude, and, or, grep, invert, unfiltered
+WHERE:: where, filter, exclude, exclude_where, and, or, grep, invert, unfiltered
+GROUP:: group, group_by, group_and_count, select_group, ungrouped
+HAVING:: having, filter, exclude, exclude_having, and, or, grep, invert, unfiltered
 ORDER:: order, order_by, order_append, order_prepend, order_more, reverse, reverse_order, unordered
 LIMIT:: limit, unlimited
 compounds:: union, intersect, except

data/doc/dataset_filtering.rdoc

@@ -59,6 +59,14 @@ Ranges (both inclusive and exclusive) can also be used:
   items.filter(:price => 100...200).sql
   #=> "SELECT * FROM items WHERE (price >= 100 AND price < 200)"
 
+== Filtering using an array
+
+If you need to select multiple items from a dataset, you can supply an array:
+
+	item_array = [1, 38, 47, 99]
+	items.filter(:id => item_array).sql
+	#=> "SELECT * FROM items WHERE (id IN (1, 38, 47, 99))"
+
 == Filtering using expressions
 
 Sequel allows you to use ruby expressions directly in the call to filter:

data/doc/mass_assignment.rdoc

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