Fixed documentation typos

doc/migration.rdoc

@@ -14,20 +14,20 @@ create the necessary database structure manually using Sequel's schema
 modification methods or another database tool.  However, if you are dealing
 with other developers, you'll have to send them all of the changes you are
 making.  Even if you aren't dealing with other developers, you generally have
-to make the schema changes in 3 places (development, testing, and 
+to make the schema changes in 3 places (development, testing, and
 production), and it's probably easier to use the migrations system to apply
 the schema changes than it is to keep track of the changes manually and
 execute them manually at the appropriate time.
 
 Sequel tracks which migrations you have already run, so to apply migrations
-you generally need to use run Sequel's migrator with <tt>bin/sequel -m</tt>:
+you generally need to run Sequel's migrator with <tt>bin/sequel -m</tt>:
 
   sequel -m path/to/migrations postgres://host/database
 
 Migrations in Sequel use a very simple DSL via the <tt>Sequel.migration</tt>
 method, and inside the DSL, use the <tt>Sequel::Database</tt> schema
 modification methods such as +create_table+ and +alter_table+.
-See the {schema modification guide}[link:files/doc/schema_modification_rdoc.html] 
+See the {schema modification guide}[link:files/doc/schema_modification_rdoc.html]
 for details on the schema modification methods you can use.
 
 == A Basic Migration
@@ -267,7 +267,7 @@ is important though, as it is used to mean that all migrations should be unappli
 === +TimestampMigrator+ Filenames
 
 With the +TimestampMigrator+, the version integer should represent a timestamp, though this isn't strictly
-required.  
+required.
 
 For example, for <tt>5/10/2010 12:00:00pm</tt>, you could use any of the following formats:
 
@@ -322,8 +322,8 @@ you should give it some thought before using it.
 
 Just don't do it.
 
-In general, you should not modify any migration that has been run on the database and been committed
-the source control repository, unless the migration contains a error that causes data loss.  As long
+In general, you should not modify any migration that has been run on the database and been committed to
+the source control repository, unless the migration contains an error that causes data loss.  As long
 as it is possible to undo the migration without losing data, you should just add another migration
 that undoes the actions of the previous bad migration, and maybe does the correct action afterward.
 
@@ -358,7 +358,7 @@ or they should use the reversible migrations feature with a +change+ block:
 It's usually easy to determine what you should put in your migration's +up+ block,
 as it's whatever change you want to make to the database.  The +down+ block is
 less obvious.  In general, it should reverse the changes made by the +up+ block, which means
-it should execute the opposite of what the +up+ block does in the reverse order in which 
+it should execute the opposite of what the +up+ block does in the reverse order in which
 the +up+ block does it.  Here's an example where you are switching from having a single
 artist per album to multiple artists per album:
 
@@ -402,12 +402,12 @@ artist per album to multiple artists per album:
     end
   end
 
-Note that the order in which things were done in the +down+ block is in
-reverse order to how they were done in the +up+ block.  Also note how it
-isn't always possible to reverse exactly what was done in the +up+ block.
-You should try to do so as much as possible, but if you can't, you may
-want to have your +down+ block raise a <tt>Sequel::Error</tt> exception
-saying why the migration cannot be reverted.
+Note that the operations performed in the +down+ block are performed in the
+reverse order of how they are performed in the +up+ block.  Also note how it
+isn't always possible to reverse exactly what was done in the +up+ block.  You
+should try to do so as much as possible, but if you can't, you may want to have
+your +down+ block raise a <tt>Sequel::Error</tt> exception saying why the
+migration cannot be reverted.
 
 == Running migrations
 

doc/release_notes/3.29.0.txt

@@ -130,7 +130,7 @@
 * Database#<< and Dataset#<< now return self, which allow them
   to be used in chaining:
 
-    DB << "UPADTE foo SET bar_id = NULL" << "DROP TABLE bars"
+    DB << "UPDATE foo SET bar_id = NULL" << "DROP TABLE bars"
     DB[:foo] << {:bar_id=>0} << DB[:bars].select(:id)
 
 * A Database#timezone accessor has been added, allowing you to

lib/sequel/database/query.rb

@@ -39,7 +39,7 @@ class Database
     # Runs the supplied SQL statement string on the database server.
     # Returns self so it can be safely chained:
     #
-    #   DB << "UPADTE albums SET artist_id = NULL" << "DROP TABLE artists"
+    #   DB << "UPDATE albums SET artist_id = NULL" << "DROP TABLE artists"
     def <<(sql)
       run(sql)
       self

lib/sequel/model/associations.rb

@@ -704,7 +704,7 @@ def apply_association_dataset_opts(opts, ds)
         #           singularized unless the type is :many_to_one or :one_to_one)
         # :clone :: Merge the current options and block into the options and block used in defining
         #           the given association.  Can be used to DRY up a bunch of similar associations that
-        #            all share the same options such as :class and :key, while changing the order and block used.
+        #           all share the same options such as :class and :key, while changing the order and block used.
         # :conditions :: The conditions to use to filter the association, can be any argument passed to filter.
         # :dataset :: A proc that is instance_evaled to get the base dataset
         #             to use for the _dataset method (before the other options are applied).
@@ -809,9 +809,9 @@ def apply_association_dataset_opts(opts, ds)
         #                 Defaults to primary key of the current table. Can use an
         #                 array of symbols for a composite key association.
         # :primary_key_column :: Similar to, and usually identical to, :primary_key, but :primary_key refers
-        #                to the model method call, where :primary_key_column refers to the underlying column.
-        #                Should only be used if the the model method differs from the primary key column, in
-        #                conjunction with defining a model alias method for the primary key column.
+        #                        to the model method call, where :primary_key_column refers to the underlying column.
+        #                        Should only be used if the the model method differs from the primary key column, in
+        #                        conjunction with defining a model alias method for the primary key column.
         # === :many_to_many
         # :graph_join_table_block :: The block to pass to +join_table+ for
         #                            the join table when eagerly loading the association via +eager_graph+.
@@ -833,17 +833,17 @@ def apply_association_dataset_opts(opts, ds)
         # :join_table_block :: proc that can be used to modify the dataset used in the add/remove/remove_all
         #                      methods.  Should accept a dataset argument and return a modified dataset if present.
         # :left_key :: foreign key in join table that points to current model's
-        #              primary key, as a symbol. Defaults to :"#{self.name.underscore}_id".  
+        #              primary key, as a symbol. Defaults to :"#{self.name.underscore}_id".
         #              Can use an array of symbols for a composite key association.
         # :left_primary_key :: column in current table that :left_key points to, as a symbol.
         #                      Defaults to primary key of current table.  Can use an
         #                      array of symbols for a composite key association.
         # :left_primary_key_column :: Similar to, and usually identical to, :left_primary_key, but :left_primary_key refers to
-        #                the model method to call, where :left_primary_key_column refers to the underlying column.  Should only
-        #                be used if the model method differs from the left primary key column, in conjunction
-        #                with defining a model alias method for the left primary key column.
+        #                             the model method to call, where :left_primary_key_column refers to the underlying column.  Should only
+        #                             be used if the model method differs from the left primary key column, in conjunction
+        #                             with defining a model alias method for the left primary key column.
         # :right_key :: foreign key in join table that points to associated
-        #               model's primary key, as a symbol.  Defaults to Defaults to :"#{name.to_s.singularize}_id".
+        #               model's primary key, as a symbol.  Defaults to :"#{name.to_s.singularize}_id".
         #               Can use an array of symbols for a composite key association.
         # :right_primary_key :: column in associated table that :right_key points to, as a symbol.
         #                       Defaults to primary key of the associated table.  Can use an