sequel 5.45.0 → 5.77.0

data/bin/sequel

@@ -194,7 +194,11 @@ begin
     TO_DB = connect_proc[db2]
     same_db = DB.database_type==TO_DB.database_type
     index_opts = {:same_db=>same_db}
+
+    # :nocov:
     index_opts[:index_names] = :namespace if !DB.global_index_namespace? && TO_DB.global_index_namespace?
+    # :nocov:
+
     if DB.database_type == :sqlite && !same_db
       # SQLite integer types allows 64-bit integers
       TO_DB.extension :integer64
@@ -212,18 +216,20 @@ begin
     puts "Begin copying data"
     DB.transaction do
       TO_DB.transaction do
+        all_status_lines = ENV['SEQUEL_BIN_STATUS_ALL_LINES']
+
         DB.tables.each do |table|
           puts "Begin copying records for table: #{table}"
           time = Time.now
           to_ds = TO_DB.from(table)
           j = 0
           DB.from(table).each do |record|
-            if Time.now - time > 5
+            to_ds.insert(record)
+            j += 1
+            if Time.now - time > 5 || all_status_lines
               puts "Status: #{j} records copied" 
               time = Time.now
             end
-            to_ds.insert(record)
-            j += 1
           end
           puts "Finished copying #{j} records for table: #{table}"
         end
@@ -260,8 +266,10 @@ if !ARGV.empty?
   ARGV.each{|v| load(v)}
 elsif !$stdin.isatty
   eval($stdin.read)
+# :nocov:
 else
   require 'irb'
   puts "Your database is stored in DB..."
   IRB.start
 end
+# :nocov:

data/doc/advanced_associations.rdoc

@@ -115,7 +115,7 @@ These two approaches can also be nested, with +eager+ -> +eager_graph+ -> +eager
 
 Or with 2 separate +eager_graph+ queries:
 
-  Artist.eager_graph(:albums).eager_graph_eager([:albums], :tracks=>proc{|ds| ds.eager_graph(:lyric)})
+  Artist.eager_graph(:albums).eager_graph_eager([:albums], tracks: proc{|ds| ds.eager_graph(:lyric)})
   # 2 Queries:
   # SELECT artists.id, artists.name, ...
   #        albums.id AS albums_id, albums.name AS albums_name, ...
@@ -238,9 +238,9 @@ have the following associations
     
 and the following three albums in the database:
 
-  album1 = Album.create(:artist_id=>3) # id: 1
-  album2 = Album.create(:artist_id=>3) # id: 2
-  album3 = Album.create(:artist_id=>2) # id: 3
+  album1 = Album.create(artist_id: 3) # id: 1
+  album2 = Album.create(artist_id: 3) # id: 2
+  album3 = Album.create(artist_id: 2) # id: 3
 
 If you try to eager load this dataset:
 
@@ -256,7 +256,7 @@ the are both in the array related to that key.  album3 has a different
 artist_id, so it is in a different array. Eager loading of artists is
 done by looking for any artist having one of the keys in the hash:
 
-  artists = Artist.where(:id=>id_map.keys).all
+  artists = Artist.where(id: id_map.keys).all
 
 When the artists are retrieved, you can iterate over them, find entries
 with matching keys, and manually associate them to the albums:
@@ -281,7 +281,7 @@ case each array only has a single object, because id is the primary key).  So wh
 looking for tracks to eagerly load, you only need to look for ones that have an
 album_id with one of the keys in the hash:
 
-  tracks = Track.where(:album_id=>id_map.keys).all
+  tracks = Track.where(album_id: id_map.keys).all
 
 When the tracks are retrieved, you can iterate over them, find entries with matching
 keys, and manually associate them to the albums:
@@ -314,10 +314,10 @@ artist or tracks method on the album will not do another database lookup.
 
 So putting everything together, the artist eager loader looks like:
 
-  Album.many_to_one :artist, :eager_loader=>(proc do |eo_opts|
+  Album.many_to_one :artist, eager_loader: (proc do |eo_opts|
     eo_opts[:rows].each{|album| album.associations[:artist] = nil}
     id_map = eo_opts[:id_map]
-    Artist.where(:id=>id_map.keys).all do |artist|
+    Artist.where(id: id_map.keys).all do |artist|
       if albums = id_map[artist.id]
         albums.each do |album|
           album.associations[:artist] = artist
@@ -328,10 +328,10 @@ So putting everything together, the artist eager loader looks like:
 
 and the tracks eager loader looks like:
 
-  Album.one_to_many :tracks, :eager_loader=>(proc do |eo_opts|
+  Album.one_to_many :tracks, eager_loader: (proc do |eo_opts|
     eo_opts[:rows].each{|album| album.associations[:tracks] = []}
     id_map = eo_opts[:id_map]
-    Track.where(:album_id=>id_map.keys).all do |track|
+    Track.where(album_id: id_map.keys).all do |track|
       if albums = id_map[track.album_id]
         albums.each do |album|
           album.associations[:tracks] << track
@@ -405,7 +405,7 @@ the window function strategy:
 
   Artist.one_to_many :first_10_albums, class: :Album, order: :release_date, limit: 10,
     eager_limit_strategy: :window_function
-  Artist.where(:id=>[1,2]).eager(:first_10_albums).all
+  Artist.where(id: [1,2]).eager(:first_10_albums).all
   # SELECT * FROM (
   #   SELECT *, row_number() OVER (PARTITION BY albums.artist_id ORDER BY release_date) AS x_sequel_row_number_x
   #   FROM albums
@@ -483,7 +483,7 @@ function:
 The :correlated_subquery approach JOINs to a nested subquery using a correlated
 subquery:
 
-  Artist.eager_graph_with_options(:first_10_albums, :limit_strategy=>:correlated_subquery).all
+  Artist.eager_graph_with_options(:first_10_albums, limit_strategy: :correlated_subquery).all
   # SELECT artists.id, artists.name, first_10_albums.id AS first_10_albums_id,
   #        first_10_albums.name AS first_10_albums_name, first_10_albums.artist_id,
   #        first_10_albums.release_date
@@ -670,8 +670,10 @@ polymorphic associations in Sequel about as easy as it is in ActiveRecord.  Howe
 here's how they can be done using Sequel's custom associations (the sequel_polymorphic
 external plugin is just a generic version of this code):
 
+  Sequel.extension :inflector # for attachable_type.constantize
+
   class Asset < Sequel::Model
-    many_to_one :attachable, reciprocal: :assets,
+    many_to_one :attachable, reciprocal: :assets, reciprocal_type: :one_to_many,
       setter: (lambda do |attachable|
         self[:attachable_id] = (attachable.pk if attachable)
         self[:attachable_type] = (attachable.class.name if attachable)
@@ -853,7 +855,7 @@ associated tickets.
   class Project < Sequel::Model
     one_to_many :tickets
     many_to_one :ticket_hours, read_only: true, key: :id,
-     dataset: proc{Ticket.where(:project_id=>id).select{sum(hours).as(hours)}},
+     dataset: proc{Ticket.where(project_id: id).select{sum(hours).as(hours)}},
      eager_loader: (lambda do |eo|
       eo[:rows].each{|p| p.associations[:ticket_hours] = nil}
       Ticket.where(project_id: eo[:id_map].keys).

data/doc/association_basics.rdoc

@@ -41,7 +41,7 @@ As is the code to add a related album to an artist:
 
   @artist.add_album(name: 'RF')
 
-It also makes it easier to creating queries that use joins based on the association:
+It also makes it easier to create queries that use joins based on the association:
 
   Artist.association_join(:albums)
   # SELECT * FROM artists
@@ -63,8 +63,8 @@ It ships with additional association types via plugins.
 
 The many_to_one association is used when the table for the current class
 contains a foreign key that references the primary key in the table for the
-associated class.  It is named because there can be many rows in the current
-table for each row in the associated table.
+associated class.  It is named 'many_to_one' because there can be many rows
+in the current table for each row in the associated table.
 
   # Database schema:
   #  albums             artists
@@ -81,8 +81,8 @@ table for each row in the associated table.
 
 The one_to_many association is used when the table for the associated class
 contains a foreign key that references the primary key in the table for the
-current class.  It is named because for each row in the current table there
-can be many rows in the associated table:
+current class.  It is named 'one_to_many' because for each row in the
+current table there can be many rows in the associated table:
 
 The one_to_one association can be thought of as a subset of the one_to_many association,
 but where there can only be either 0 or 1 records in the associated table.  This is
@@ -320,11 +320,11 @@ Associations are cached after being retrieved:
   @album.artists # Cached - No Database Query
   
 You can choose to ignore the cached versions and do a database query to
-retrieve results by passing a :reload=>true option to the association method:
+retrieve results by passing a <tt>reload: true</tt> option to the association method:
 
   @album.artists # Not cached - Database Query
   @album.artists # Cached - No Database Query
-  @album.artists(:reload=>true) # Ignore cache - Database Query
+  @album.artists(reload: true) # Ignore cache - Database Query
 
 If you reload/refresh the object, it will automatically clear the
 associations cache for the object:
@@ -342,9 +342,15 @@ instance method:
   @album.artists # [<Artist ...>, ...]
   @album.associations[:artists] # [<Artist ...>, ...]
 
+=== Code Reloading
+
+When declaring associations, Sequel caches association metadata in the association reflection. If you're doing any code reloading that doesn't involve restarting the related process, you should disable caching of the association reflection, to avoid stale model classes still being referenced after reloading:
+
+  Sequel::Model.cache_associations = false
+
 == Dataset Method
 
-In addition to the above methods, associations also add a instance method
+In addition to the above methods, associations also add an instance method
 ending in +_dataset+ that returns a dataset representing the objects in the associated table:
 
   @album.artist_id
@@ -532,14 +538,14 @@ Which could be created using the following Sequel code:
   DB.create_table(:artists) do
     # Primary key must be set explicitly
     primary_key :id
-    String :name, :null=>false, :unique=>true
+    String :name, null: false, unique: true
   end
   DB.create_table(:albums) do
     primary_key :id
     # Table that foreign key references needs to be set explicitly
     # for a database foreign key reference to be created.
-    foreign_key :artist_id, :artists, :null=>false
-    String :name, :null=>false, :unique=>true
+    foreign_key :artist_id, :artists, null: false
+    String :name, null: false, unique: true
   end
 
 If you already had a schema such as:
@@ -552,7 +558,7 @@ If you already had a schema such as:
 Then you just need to add the column:
 
   DB.alter_table(:albums) do
-    add_foreign_key :artist_id, :artists, :null=>false
+    add_foreign_key :artist_id, :artists, null: false
   end
 
 === many_to_many
@@ -588,11 +594,11 @@ wanted to add an albums_artists join table to create the following schema:
 
 You could use the following Sequel code:
 
-  DB.create_join_table(:album_id=>:albums, :artist_id=>:artists)
+  DB.create_join_table(album_id: :albums, artist_id: :artists)
   # or
   DB.create_table(:albums_artists) do
-    foreign_key :album_id, :albums, :null=>false
-    foreign_key :artist_id, :artists, :null=>false
+    foreign_key :album_id, :albums, null: false
+    foreign_key :artist_id, :artists, null: false
     primary_key [:album_id, :artist_id]
     index [:artist_id, :album_id]
   end
@@ -713,7 +719,7 @@ saving the passed in (or newly created) object.  However, to avoid
 silent failures of these methods, they explicitly raise exceptions
 even when raise_on_save_failure is false for the associated model.
 You can disable this behavior (i.e. return nil instead of raising
-exceptions on a save failure) by setting the <tt>:raise_on_save_failure=>false</tt>
+exceptions on a save failure) by setting the <tt>raise_on_save_failure: false</tt>
 option for the association.
 
 === remove_<i>association</i>(object_to_disassociate) (e.g. remove_album) [+one_to_many+ and +many_to_many+]
@@ -826,6 +832,8 @@ you also wanted to handle the Artist#add_album method:
     end)
   end
 
+You can set this to +nil+ to not create a add_<i>association</i> method.
+
 === :remover (\_remove_<i>association</i> method)
 
 Continuing with the same example, here's how you would handle the same case if
@@ -837,6 +845,8 @@ you also wanted to handle the Artist#remove_album method:
     end)
   end
 
+You can set this to +nil+ to not create a remove_<i>association</i> method.
+
 === :clearer (\_remove_all_<i>association</i> method)
 
 Continuing with the same example, here's how you would handle the same case if
@@ -850,6 +860,22 @@ you also wanted to handle the Artist#remove_all_albums method:
     end)
   end
 
+You can set this to +nil+ to not create a remove_all_<i>association</i> method.
+
+=== :no_dataset_method
+
+Setting this to true will result in the <i>association</i>_dataset method
+not being defined. This can save memory if you only use the <i>association</i>
+method and do not call the <i>association</i>_dataset method directly or
+indirectly.
+
+=== :no_association_method
+
+Setting this to true will result in the <i>association</i> method
+not being defined. This can save memory if you only use the
+<i>association</i>_dataset method and do not call the <i>association</i> method
+directly or indirectly.
+
 == Association Options
 
 Sequel's associations mostly share the same options.  For ease of understanding,
@@ -961,7 +987,7 @@ If you do not use a hash or array of two element arrays, you should use the
 :graph_conditions, :graph_only_conditions, or :graph_block option or you will not
 be able to use eager_graph or association_join with the association.
 
-  Artist.one_to_many :good_albums, class: :Album, conditions: {:good=>true}
+  Artist.one_to_many :good_albums, class: :Album, conditions: {good: true}
   @artist.good_albums
   # SELECT * FROM albums WHERE ((artist_id = 1) AND (good IS TRUE))
 
@@ -1087,7 +1113,7 @@ already applied, and the proc should return a modified copy of this dataset.
 Here's an example of an association of songs to artists through lyrics, where
 the artist can perform any one of four tasks for the lyric:
 
-  Album.one_to_many :songs, dataset: (lambda do |r|
+  Artist.one_to_many :songs, dataset: (lambda do |r|
     r.associated_dataset.select_all(:songs).
      join(:lyrics, id: :lyricid, id=>[:composer_id, :arranger_id, :vocalist_id, :lyricist_id])
   end)
@@ -1142,10 +1168,27 @@ join of the join table and the associated table, whereas this option just
 applies to the join table.  It can be used to make sure that filters are used
 when deleting.
 
-  Artist.many_to_many :lead_guitar_albums, class: :Album, :join_table_block=>(lambda do |ds|
+  Artist.many_to_many :lead_guitar_albums, class: :Album, join_table_block: (lambda do |ds|
     ds.where(instrument_id: 5)
   end)
 
+==== :join_table_db [+many_to_many+, +one_through_one+]
+
+A Sequel::Database to use for the join table.  Specifying this option switches the
+loading to use a separate query for the join table.  This is useful if the
+join table is not located in the same database as the associated table, or
+if the database account with access to the associated table doesn't have
+access to the join table.
+
+For example, if the Album class uses a different Sequel::Database than the Artist
+class, and the join table is in the database that the Artist class uses:
+
+  Artist.many_to_many :lead_guitar_albums, class: :Album, join_table_db: Artist.db
+
+This option also affects the add/remove/remove_all methods, by changing
+which database is used for inserts/deletes from the join table (add/remove/remove_all
+defaults to use the current model's database instead of the associated model's database).
+
 === Callback Options
 
 All callbacks can be specified as a Symbol, Proc, or array of both/either
@@ -1433,7 +1476,7 @@ at least the following keys:
 Example:
 
   Artist.one_to_many :self_title_albums, class: :Album,
-   :eager_grapher=>(lambda do |eo|
+   eager_grapher: (lambda do |eo|
     eo[:self].graph(:albums, {artist_id: :id, name: :name},
       table_alias: eo[:table_alias], implicit_qualifier: eo[:implicit_qualifier])
   end)
@@ -1455,6 +1498,36 @@ as the qualifiers may not match the aliases automatically used by eager_graph.
 This should contain unqualified identifiers, and eager_graph will automatically
 qualify them with the appropriate alias.
 
+==== :graph_use_association_block
+
+Setting this to true makes eager_graph apply the association block to the
+associated dataset before graphing the associated dataset into the receiver.
+In most cases when this option is used and the association has a block, the
+dataset returned by eager_graph will contain a JOIN to a subquery.
+
+By default (when this option is not used), the association block will be ignored
+when using eager_graph:
+
+  Artist.one_to_many :tracks do |ds|
+    ds.where(foo: 3)
+  end
+  Artist.eager_graph(:tracks)
+  # SELECT albums.id, tracks.id AS tracks_id, tracks.album_id
+  # FROM albums
+  # LEFT OUTER JOIN tracks
+  # ON (tracks.album_id = albums.id)
+
+When this option is used, the block will be respected:
+
+  Artist.one_to_many :tracks, graph_use_association_block: true do |ds|
+    ds.where(foo: 3)
+  end
+  Artist.eager_graph(:tracks)
+  # SELECT albums.id, tracks.id AS tracks_id, tracks.album_id
+  # FROM albums
+  # LEFT OUTER JOIN (SELECT * FROM tracks WHERE (foo = 3)) AS tracks
+  # ON (tracks.album_id = albums.id)
+
 ==== :graph_join_table_conditions [+many_to_many+, +one_through_one+]
 
 The additional conditions to use on the SQL join for the join table when
@@ -1638,9 +1711,8 @@ For +many_to_one+ and +one_to_one+ associations, do not add a setter method.
 For +one_to_many+ and +many_to_many+, do not add the add_<i>association</i>,
 remove_<i>association</i>, or remove_all_<i>association</i> methods.
 
-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.
+If you are not using the association modification methods, setting this
+value to true will save memory.
 
 ==== :validate
 
@@ -1667,12 +1739,35 @@ If set to false, you cannot load the association eagerly via eager or
 eager_graph.
 
   Artist.one_to_many :albums, allow_eager: false
-  Artist.eager(:albums) # Raises Sequel::Error
+  Artist.eager(:albums)       # Raises Sequel::Error
+  Artist.eager_graph(:albums) # Raises Sequel::Error
 
 This is usually used if the association dataset depends on specific values in
 model instance that would not be valid when eager loading for multiple
 instances.
 
+==== :allow_eager_graph
+
+If set to false, you cannot load the association eagerly via eager_graph.
+
+  Artist.one_to_many :albums, allow_eager_graph: false
+  Artist.eager(:albums)       # Allowed
+  Artist.eager_graph(:albums) # Raises Sequel::Error
+
+This is useful if you still want to allow loading via eager, but do not want
+to allow loading via eager graph, possibly because the association does not
+support joins.
+
+==== :allow_filtering_by
+
+If set to false, you cannot use the association when filtering.
+
+  Artist.one_to_many :albums, allow_filtering_by: false
+  Artist.where(albums: Album.where(name: 'A')).all # Raises Sequel::Error
+
+This is useful if such filtering cannot work, such as when a subquery cannot
+be used because the necessary tables are not in the same database.
+
 ==== :instance_specific
 
 This allows you to override the setting of whether the dataset contains instance

data/doc/cheat_sheet.rdoc

@@ -54,8 +54,16 @@ Without a filename argument, the sqlite adapter will setup a new sqlite database
 == Update/Delete rows
 
   dataset.exclude(:active).delete
-  dataset.where{price < 100}.update(:active => true)
-  dataset.where(:active).update(:price => Sequel[:price] * 0.90)
+  dataset.where{price < 100}.update(active: true)
+  dataset.where(:active).update(price: Sequel[:price] * 0.90)
+
+= Merge rows
+
+  dataset.
+    merge_using(:table, col1: :col2).
+    merge_insert(col3: :col4).
+    merge_delete{col5 > 30}.
+    merge_update(col3: Sequel[:col3] + :col4)
 
 == Datasets are Enumerable
 
@@ -166,7 +174,7 @@ Without a filename argument, the sqlite adapter will setup a new sqlite database
     String :name, unique: true, null: false
     TrueClass :active, default: true
     foreign_key :category_id, :categories
-    DateTime :created_at, default: Sequel::CURRENT_TIMESTAMP, :index=>true
+    DateTime :created_at, default: Sequel::CURRENT_TIMESTAMP, index: true
     
     index [:category_id, :active]
   end

data/doc/mass_assignment.rdoc

@@ -48,7 +48,7 @@ If you want to change mass assignment so it ignores attempts to access restricte
 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.
 If you are dealing with untrusted input, you are generally going to want to restrict what should be updated.
 
-Sequel has <tt>Model#set_fields</tt> and <tt>Model#update_fields</tt> methods, which are designed to be used with untrused input.
+Sequel has <tt>Model#set_fields</tt> and <tt>Model#update_fields</tt> methods, which are designed to be used with untrusted input.
 These methods take two arguments, the untrusted hash as the first argument, and a trusted array of field names as the second argument:
 
   post.set_fields({title: 'T', body: 'B'}, [:title, :body])

data/doc/migration.rdoc

@@ -86,9 +86,24 @@ the following methods:
   * +add_full_text_index+
   * +add_spatial_index+
   * +rename_column+
+  * +set_column_allow_null+
 
 If you use any other methods, you should create your own +down+ block.
 
+To revert a migration created with +change+, you can copy the migration to a new file, and
+replace +change+ with +revert+. For example, if you no longer need the artists table, you
+can use the following migration.  This will drop the artists table when migrating up, and
+recreate it when migrating down:
+
+  Sequel.migration do
+    revert do
+      create_table(:artists) do
+        primary_key :id
+        String :name, null: false
+      end
+    end
+  end
+
 In normal usage, when Sequel's migrator runs, it runs the +up+ blocks for all
 migrations that have not yet been applied.  However, you can use the <tt>-M</tt>
 switch to specify the version to which to migrate, and if it is lower than the
@@ -352,7 +367,7 @@ you should give it some thought before using it.
 
 == Ignoring missing migrations
 
-In some cases, you may want to allow a migration in the database that does not exist in the filesystem (deploying to an older version of code without running a down migration when deploy auto-migrates, for example). If required, you can pass <tt>allow_missing_migration_files: true</tt> as an option. This will stop errors from being raised if there are migrations in the database that do not exist in the filesystem.
+In some cases, you may want to allow a migration in the database that does not exist in the filesystem (deploying to an older version of code without running a down migration when deploy auto-migrates, for example). If required, you can pass <tt>allow_missing_migration_files: true</tt> as an option. This will stop errors from being raised if there are migrations in the database that do not exist in the filesystem. Note that the migrations themselves can still raise an error when using this option, if the database schema isn't in the state the migrations expect it to be in.  In general, the <tt>allow_missing_migration_files: true</tt> option is very risky to use, and should only be used if it is absolutely necessary.
 
 == Modifying existing migrations
 
@@ -543,16 +558,22 @@ The main difference between the two is that <tt>-d</tt> will use the type method
 with the database independent ruby class types, while <tt>-D</tt> will use
 the +column+ method with string types.
 
-Note that Sequel cannot dump constraints other than primary key and possibly
-foreign key constraints.  If you are using database features such
-as constraints or triggers, you should use your database's dump and restore
-programs instead of Sequel's schema dumper.
-
 You can take the migration created by the schema dumper to another computer
 with an empty database, and attempt to recreate the schema using:
 
   sequel -m db/migrations postgres://host/database
 
+The schema_dumper extension is quite limited in what types of
+database objects it supports.  In general, it only supports
+dumping tables, columns, primary key and foreign key constraints,
+and some indexes.  It does not support most table options, CHECK
+constraints, partial indexes, database functions, triggers,
+security grants/revokes, and a wide variety of other useful
+database properties.  Be aware of the limitations when using the
+schema_dumper extension. If you are dumping the schema to restore
+to the same database type, it is recommended to use your database's
+dump and restore programs instead of the schema_dumper extension.
+
 == Checking for Current Migrations
 
 In your application code, you may want to check that you are up to date in

data/doc/model_hooks.rdoc

@@ -199,7 +199,7 @@ While it's not enforced anywhere, it's a good idea to make +super+ the last expr
 
     def after_save
       super
-      AuditLog.create(:log=>"Album #{name} created")
+      AuditLog.create(log: "Album #{name} created")
     end
   end
 

data/doc/object_model.rdoc

@@ -36,7 +36,7 @@ schema modification,
 and transactions:
 
   DB.transaction do
-    DB[:table].insert(:column=>value)
+    DB[:table].insert(column: value)
   end
 
 Sequel::Database#literal can be used to take any object that Sequel handles
@@ -468,7 +468,7 @@ objects:
   Sequel.lit(['', ' = '], :a, 1)
 
   '? = ?'.lit(:a, 1) # core_extensions extension
-  ':b = :v'.lit(:b=>:a, :v=>1) # core_extensions extension
+  ':b = :v'.lit(b: :a, v: 1) # core_extensions extension
 
 === Sequel::SQL::OrderedExpression
 
@@ -482,20 +482,20 @@ it ascending or descending:
 Additionally, they take an options hash, which can be used to specify how nulls
 can be sorted:
 
-  Sequel::SQL::OrderedExpression.new(:a, true, :nulls=>:first) # "a" DESC NULLS FIRST
-  Sequel::SQL::OrderedExpression.new(:a, false, :nulls=>:last) # "a" ASC NULLS LAST
+  Sequel::SQL::OrderedExpression.new(:a, true, nulls: :first) # "a" DESC NULLS FIRST
+  Sequel::SQL::OrderedExpression.new(:a, false, nulls: :last) # "a" ASC NULLS LAST
 
 The following shortcuts exist for creating Sequel::SQL::OrderedExpression objects:
 
   Sequel.asc(:a)
   Sequel.desc(:a)
-  Sequel.asc(:a, :nulls=>:first)
-  Sequel.desc(:a, :nulls=>:last)
+  Sequel.asc(:a, nulls: :first)
+  Sequel.desc(:a, nulls: :last)
 
   :a.asc # core_extensions extension
   :a.desc # core_extensions extension
-  :a.asc(:nulls=>:first) # core_extensions extension
-  :a.desc(:nulls=>:last) # core_extensions extension
+  :a.asc(nulls: :first) # core_extensions extension
+  :a.desc(nulls: :last) # core_extensions extension
 
 === Sequel::SQL::Subscript