veritas-optimizer 0.0.4 → 0.0.5

data/.travis.yml

@@ -1,8 +1,10 @@
 bundler_args: --without guard metrics
 script: "bundle exec rake spec"
 rvm:
-  - ree
   - 1.8.7
   - 1.9.2
-  - ruby-head
   - rbx
+  # - rbx-2.0
+  - ree
+  - jruby
+  - ruby-head

data/Gemfile

@@ -2,22 +2,21 @@
 
 source :rubygems
 
-gem 'veritas', '0.0.4', :git => 'git://github.com/dkubb/veritas.git'
+gem 'veritas', '~> 0.0.5', :git => 'git://github.com/dkubb/veritas.git'
 
 group :development do
-  gem 'backports', '~> 2.2.1'
-  gem 'jeweler',   '~> 1.6.0'
-  gem 'rake',      '~> 0.9.0'
+  gem 'backports', '~> 2.3.0'
+  gem 'jeweler',   '~> 1.6.4'
+  gem 'rake',      '~> 0.9.2'
   gem 'rspec',     '~> 1.3.2'
-  gem 'yard',      '~> 0.7.1'
+  gem 'yard',      '~> 0.7.2'
 end
 
 group :guard do
-  gem 'growl',         '~> 1.0.3'
-  gem 'guard',         '~> 0.3.4'
+  gem 'guard',         '~> 0.5.1'
   gem 'guard-bundler', '~> 0.1.3'
   gem 'guard-ego',     '~> 0.0.1'
-  gem 'guard-rspec',   '~> 0.3.1'
+  gem 'guard-rspec',   '~> 0.4.0'
 end
 
 platform :jruby do
@@ -31,7 +30,7 @@ platforms :mri_18 do
     gem 'flay',      '~> 1.4.2'
     gem 'flog',      '~> 2.5.1'
     gem 'heckle',    '~> 1.4.3'
-    gem 'json',      '~> 1.5.1'
+    gem 'json',      '~> 1.5.3'
     gem 'metric_fu', '~> 2.1.1'
     gem 'mspec',     '~> 1.5.17'
     gem 'rcov',      '~> 0.9.9'

data/Guardfile

@@ -14,8 +14,9 @@ guard 'rspec' do
   watch(%r{\Aspec/(?:lib|support|shared)/.+\.rb\z}) { 'spec' }
 
   # run unit specs if associated lib code is modified
-  watch(%r{\Alib/(.+)\.rb\z})                                         { |m| Dir["spec/unit/#{m[1]}"] }
-  watch("lib/#{File.basename(File.expand_path('../', __FILE__))}.rb") { 'spec'                       }
+  watch(%r{\Alib/(.+)\.rb\z})                                         { |m| Dir["spec/unit/#{m[1]}"]         }
+  watch(%r{\Alib/(veritas/optimizer)/support/(.+)\.rb\z})             { |m| Dir["spec/unit/#{m[1]}/#{m[2]}"] }
+  watch("lib/#{File.basename(File.expand_path('../', __FILE__))}.rb") { 'spec'                               }
 
   # run a spec if it is modified
   watch(%r{\Aspec/(?:unit|integration)/.+_spec\.rb\z})

data/README.rdoc

@@ -4,6 +4,61 @@ Relational algebra optimizer
 
 http://travis-ci.org/dkubb/veritas-optimizer.png
 
+== Usage
+
+  # optimize a relation
+  new_relation = relation.optimize
+  new_relation = relation.optimize(optimizer)
+
+  # optimize a scalar function
+  new_function = function.optimize
+  new_function = function.optimize(optimizer)
+
+  # optimize an aggregate function
+  new_aggregate = function.aggregate
+  new_aggregate = function.aggregate(optimizer)
+
+== Description
+
+The purpose of this gem is to provide a simple API that can be used to optimize a veritas[https://github.com/dkubb/veritas] relation, scalar or aggregate function. An optional optimizer can be passed in to the #optimize method and return an equivalent but simplified version of the object.
+
+One of the primary benefits of Relational Algebra is that it's based on logic, and the rules for simplifying logic are well known and studied. An optimizer can pass through user-generated objects and typically find ways to simplify or organize them in a way that will be more efficient when the operation is executed.
+
+The goal is not to replace the advanced optimizers that are inside most databases and datastores, but to augment it with some simple optimizations that make the user provided query easier for the datastore to accept. On the ruby side we have knowledge about intent and can perform semantic optimization that the datastore otherwise would not be able to perform. In many cases we have richer constraints and data than many datastores and we can use that information to simplify and possibly short-circuit queries that could otherwise never return valid results.
+
+With the ability to provide custom optimizers we can even target output to a structure optimized for specific datastores. All operations in relational algebra can be transformed into other equivalent operations, ones that are more efficient for the target datastore to execute. The built-in optimizers included in this gem are only a starting point; the intention is to expand them as well as help others create custom optimizers that are optimized for each datastore.
+
+== Design
+
+The contract for an optimizer instance is simple:
+
+  a) it must respond to #call, and accept an optimizable object as it's only argument
+  b) it must return an equivalent object
+  c) it must return the exact object when it cannot perform further optimizations
+
+The optimizer can perform whatever logic it wishes on the object or any of it's contained objects as far down the tree as it likes as long as the requirements for (b) and (c) are met.
+
+Inside this gem we have the concept of an optimizer chain. It's a chain of responsibility, which means it's a set of objects chained together to form a pipeline. The object is passed into the head of the pipeline and is either matched and returned by one of the optimizers, or it is already fully optimized and passes through to the end of the chain and is returned as-is. This chain organization has proven to be extremely effective, and it is trivial to re-order or add new optimizers into the middle of the chain as needed. Further work will be made to provide APIs to make this even simpler.
+
+Here is an example of an optimizer chain for the restriction operator (think WHERE clause in SQL):
+
+  Veritas::Algebra::Restriction.optimizer = chain(
+    Tautology,            # does the predicate match everything?
+    Contradiction,        # does the predicate match nothing?
+    RestrictionOperand,   # does the restriction contain another restriction?
+    SetOperand,           # does the restriction contain a set operation?
+    OrderOperand,         # does the restriction contain an order?
+    EmptyOperand,         # does the restriction contain an empty relation?
+    MaterializedOperand,  # does the restriction contain a materialized relation?
+    UnoptimizedOperand    # does the restriction contain an unoptimized relation?
+  )
+
+The restriction operator enters this pipeline, and tests are made at each stage. If the test returns true, then an optimization is performed. Usually the goal is to eliminate work performed by the system or collapse the tree of operations down into something simpler. More aggressive optimizations are usually checked first because we would like to prune as much of the tree as possible up-front. In this case, the first test checks to see if the restriction matches everything, in which case it's pretty much a no-op, and we can drop it altogether. If that's not the case, we then test to see if it matches nothing, if that's the case then we can return an empty relation. Then we test if it's another restriction, in which case we can "AND" the predicates for both restrictions together and return a single restriction operation. And so on down the list with the first match winning.
+
+We always perform at least two optimization passes on each object, because once a tree has been simplified there could be further optimizations possible. Essentially we keep passing the objects into their corresponding optimizer chains until it passes through unchanged. This may seem rather expensive, and I guess it is, but optimization is very fast. Also it doesn't appear to affect performance much in practice due to our convention of testing for the most aggressive optimizations first; often it results in something that is completely optimized on the first try.
+
+Once the optimization passes are finished, and no further optimization is possible, the result of an #optimize call is memoized. Further calls to #optimize will always return the same object.
+
 == Note on Patches/Pull Requests
 
 * If you want your code merged into the mainline, please discuss

data/Rakefile

@@ -5,7 +5,7 @@ require 'rake'
 require File.expand_path('../lib/veritas/optimizer/version', __FILE__)
 
 begin
-  gem('jeweler', '~> 1.6.0') if respond_to?(:gem, true)
+  gem('jeweler', '~> 1.6.2') if respond_to?(:gem, true)
   require 'jeweler'
 
   Jeweler::Tasks.new do |gem|
@@ -23,5 +23,5 @@ begin
 
   FileList['tasks/**/*.rake'].each { |task| import task }
 rescue LoadError
-  puts 'Jeweler (or a dependency) not available. Install it with: gem install jeweler -v 1.6.0'
+  puts 'Jeweler (or a dependency) not available. Install it with: gem install jeweler -v 1.6.2'
 end

data/TODO

@@ -1,25 +1,56 @@
-* All relations, even optimized ones, need to hold a reference to the
-  original (possibly optimized) operations.
-  * Especially "empty" relations should hold a reference to the original
-    relation so that insert/update can be performed on them if they are
-    empty not because they are valid, but because the source object is empty
-  * Materialized relations will need references to the original objects.
+* Pull up Rename rather than pushing it down
+  * Currently a Rename applies to every tuple in a result-set, and
+    doing the rename prematurely means that lots of tuples that would
+    otherwise be filtered out are going to be processed. A better
+    approach should be to push the rename up, dropping renames that
+    are projected away. It should not distribute over Binary ops
+    unless the other side of the binary op has he same aliases.
 
-* Optimization can replace one or more AST nodes with a simpler/more efficient
-  structure as long as it is lossless. Just changing it to empty or
-  materialized, the way things are now, we lose what the original relation
-  was so it becomes impossible to insert/update/delete from those relations.
-  * A write to a materialized object should first propagate the write down
-    to the @operand, allowing it to raise exceptions if it's read*only,
-    then it should make the change in the materialized object.
+* For Binary operations, when the left or right is materialized then
+  change the other relation to use a restriction to filter the records.
+  * This will help optimize the fetching of the underlying records.
+
+* Convert all the direct Veritas class usage to use the corresponding
+  methods. So for example instead of Algebra::Join.new(left, right) I
+  would want left.join(right).
+  * The reason for this is that as the Relation Gateway is created
+    it will have operands that will not be directly joinable without
+    gateway specific processing. By using the method directly I give the
+    chance for the gateway to step in and perform other work before
+    delegating up to the built-in operators in veritas.
+
+* More optimizations:
+  * Union
+    * A Union of relations with the same base, header, and restrictions should
+      try to combine into a single relation with the restrictions using OR.
+
+  * Intersection
+    * An Intersection of relations with the same base, header, and restrictions
+      should try to combine into a single relation with the restrictions using
+      AND.
+    * Use the Join::RightMaterializedOperand and Join::LeftMaterializedOperand
+      optimizers to simplify Intersection operations
+
+  * Difference
+    * A Difference of relations with the same base and restrictions should
+      try to combine into a single relation with the restrictions using NOT.
+
+  * Summarization
+    * Add OrderSummarizePer for factoring out Order objects inside a Summarization
+    * When there are no aggregate functions, drop the Summarization and
+      return the summarize_per (?)
+      * Use the UnchangedHeader optimizer as a base class
+    * When summarize_per is an Order, the Order can be dropped.
 
-* Add further optimizations:
   * Projection
-    * When it contains a Rename, if the renamed attributes are removed,
-      then the rename can be removed.
     * When it contains a Restriction, if the removed attributes are *not*
       used in the predicate, then move the Restriction to contain the
       Projection.
+    * When a Projection contains a Restriction, wrap the Projection
+      in the Restriction, projecting away any attributes not used in
+      the restriction. If there are any remaining attributes, then
+      wrap the operation in a Projection removing those attributes.
+      * If all attributes are being used in the Restriction do nothing
     * When renames or extensions or summarizations are projected away and
       not used in any intermediary operation, then they can be dropped
       altogether. There's no point in going through all that work to
@@ -27,90 +58,61 @@
       the renames/extensions/summarizations to not add the attribute, and
       then call optimize again on the op to potentially remove the op altogether
       (like in the case of an extension adding one attribute that is removed).
-  * Operation Order:
-    * Projection containing an Order
-      * Should remove the Order, since it is a noop
-    * Projection should follow Rename
-      * When a Projection contains a Restriction, wrap the Projection
-        in the Restriction, projecting away any attributes not used in
-        the restriction. If there are any remaining attributes, then
-        wrap the operation in a Projection removing those attributes.
-        * If all attributes are being used in the Restriction do nothing
-      * When a Projection contains a Join, wrap the Join with a Projection
-        of all the headers, minus those used in the Join. If there were
-        any used, then wrap the whole operation in a Projection with
-        the remaining attributes.
-        * If all the attributes are used in the Join, do nothing
-        * Try to use the same approach for Product
-        * Test if it's possible to fully distribute projections over
-          joins rather than splitting it up like this.
-    * Restriction should follow Projection
-      * Restriction optimizations:
-        * "attr > ? OR attr > ?" -> "attr > ?", with the least restrictive value
-          * Do the same for >=, <, <=
-        * "attr > ? AND attr > ?" -> "attr > ?", with the most restrictive value
-          * Do the same for >=, <, <=
-        * "attr > 5 OR attr == 5" -> "attr >= 5"
-        * "attr < 5 OR attr == 5" -> "attr <= 5"
-        * "attr" = "string" AND "attr" =~ /string/ -> "attr" = "string"
-          * If the regexp matches the constant, then it should be
-            optimized down to a constant match. If it does not match
-            then it should be optimized to a Contradiction.
-        * Constant folding, eg:
-          "attr1 > attr2 AND attr1 = 5" -> "5 > attr2 AND attr1 = 5"
-          * This will probably only work across Conjunctions.
-        * "attr > 5 AND attr = 6" -> "attr = 6", because attr must be
-          equal to 6. this will probably be related to constant folding;
-          the first expression will become 6 > 5, which evaluates to a
-          Tautology, then the expression is a Tautology AND attr = 6,
-          which simplifies down to attr = 6.
-        * "attr < 5 AND attr = 6" -> "Contradiction", because attr must be equal to
-          6, and 6 < 5 evaluates to a Contradiction.  A Contradiction AND attr = 6
-          simplifies down to a Contradiction.
-      * Figure out how to reorganize the Restriction predicates so that all
-        similar operations are closer together to allow more efficient
-        optimizations. This would allow optimizations of stuff like this:
+    * It does not distribute over Intersection or Difference, but see if
+      perhaps an exception can be made if there is a functional dependency
+      between the columns projected away and the one remaining. Then I *think*
+      it might still work, but more research will be needed.
+    * When a Projection contains a Join, wrap the Join with a Projection
+      of all the headers, minus those used in the Join. If there were
+      any used, then wrap the whole operation in a Projection with
+      the remaining attributes.
+      * If all the attributes are used in the Join, do nothing
+      * Try to use the same approach for Product
+      * Test if it's possible to fully distribute projections over
+        joins rather than splitting it up like this.
+
+  * Rename
+    * When wrapping a Summarization or Extension, and renaming the new attribute,
+      it should change the new attribute name, and remove it from the rename.
+
+  * Restriction
+    * Figure out how to reorganize the Restriction predicates so that all
+      similar operations are closer together to allow more efficient
+      optimizations. This would allow optimizations of stuff like this:
+
+        "attr1 = ? OR attr2 = ? OR attr1 = ?"
 
-          "attr1 = ? OR attr2 = ? OR attr1 = ?"
+      Into:
 
-        Into:
+        "attr1 IN(..) OR attr2 = ?"
 
-          "attr1 IN(..) OR attr2 = ?"
-    * Rename should distribute over Join, Product and Set operations
-      * The goal should be to push Rename as close to the base tables
-        as possible so that the names of attribute will be consistent
-        throughout the whole tree.
-  * A Union of relations with the same base, header, and restrictions should
-    try to combine into a single relation with the restrictions using OR.
-  * An Intersection of relations with the same base, header, and restrictions
-    should try to combine into a single relation with the restrictions using
-    AND.
-  * A Difference of relations with the same base and restrictions should
-    try to combine into a single relation with the restrictions using NOT.
-  * Join Optimizations
-    * When a Join contains a Join, and the size of the base relations is
-      known, join the smallest with the largest, and then join that result
-      with the remaining relation.
-    * Make sure the smallest relation (with a known size) is always the
-      right-most operation.
-  * When a restriction uses a unique index:
-    * Order can be factored out
-    * Limit with a limit >= 1 can be factored out
-    * Offset with an offset > 0 can be transformed into an empty
-      relation, since at most there can be only one match.
+    * When it has an equality on a unique attribute:
+      * Limit with a limit >= 1 can be factored out
+      * Offset with an offset > 0 can be transformed into an empty
+        relation, since at most there can be only one match.
 
-* Summarization
-  * Add OrderSummarizePer for factoring out Order objects inside a Summarization
-  * When there are no aggregate functions, drop the Summarization and
-    return the summarize_per (?)
-    * Use the UnchangedHeader optimizer as a base class
-  * When summarize_per is TABLE_DEE, and it is wrapped by Order, at most only
-    one row can be returned, so Order can probably be dropped.
-    * Consider making relations that represents a 0 or 1 tuple relations
-      and use them in this case.
+  * Connective
+    * "attr > ? OR attr > ?" -> "attr > ?", with the least restrictive value
+      * Do the same for >=, <, <=
+    * "attr > ? AND attr > ?" -> "attr > ?", with the most restrictive value
+      * Do the same for >=, <, <=
+    * "attr > 5 OR attr == 5" -> "attr >= 5"
+    * "attr < 5 OR attr == 5" -> "attr <= 5"
+    * "attr" = "string" AND "attr" =~ /string/ -> "attr" = "string"
+      * If the regexp matches the constant, then it should be
+        optimized down to a constant match. If it does not match
+        then it should be optimized to a Contradiction.
+    * Constant folding, eg:
+      "attr1 > attr2 AND attr1 = 5" -> "5 > attr2 AND attr1 = 5"
+      * This will probably only work across Conjunctions.
+    * "attr > 5 AND attr = 6" -> "attr = 6", because attr must be
+      equal to 6. this will probably be related to constant folding;
+      the first expression will become 6 > 5, which evaluates to a
+      Tautology, then the expression is a Tautology AND attr = 6,
+      which simplifies down to attr = 6.
+    * "attr < 5 AND attr = 6" -> "Contradiction", because attr must be equal to
+      6, and 6 < 5 evaluates to a Contradiction.  A Contradiction AND attr = 6
+      simplifies down to a Contradiction.
 
-* Projection
-  * It does not distribute over Intersection or Difference, but see if
-    perhaps an exception can be made if there is a functional dependency
-    between the columns projected away and the one remaining. Then I *think*
-    it might still work, but more research will be needed.
+  * Inclusion/Exclusion
+    * When the enumerable is a contiguous sequence transform it into a Range

data/config/flay.yml

@@ -1,3 +1,3 @@
 ---
-threshold: 126
-total_score: 870
+threshold: 120
+total_score: 942

data/config/flog.yml

@@ -1,2 +1,2 @@
 ---
-threshold: 11.6
+threshold: 19.9

data/config/roodi.yml

@@ -5,11 +5,11 @@ CaseMissingElseCheck:            { }
 ClassLineCountCheck:             { line_count: 396 }
 ClassNameCheck:                  { pattern: !ruby/regexp /\A(?:[A-Z]+|[A-Z][a-z](?:[A-Z]?[a-z])+)\z/ }
 ClassVariableCheck:              { }
-CyclomaticComplexityBlockCheck:  { complexity: 2 }
+CyclomaticComplexityBlockCheck:  { complexity: 5 }
 CyclomaticComplexityMethodCheck: { complexity: 6 }
 EmptyRescueBodyCheck:            { }
 ForLoopCheck:                    { }
-MethodLineCountCheck:            { line_count: 9 }
+MethodLineCountCheck:            { line_count: 11 }
 MethodNameCheck:                 { pattern: !ruby/regexp /\A(?:[a-z\d](?:_?[a-z\d])+[?!=]?|\[\]=?|==|<=>|[+*&|-])\z/ }
 ModuleLineCountCheck:            { line_count: 398 }
 ModuleNameCheck:                 { pattern: !ruby/regexp /\A(?:[A-Z]+|[A-Z][a-z](?:[A-Z]?[a-z])+)\z/ }

data/config/site.reek

@@ -8,10 +8,10 @@ UncommunicativeParameterName:
   - !ruby/regexp /[0-9]$/
   - !ruby/regexp /[A-Z]/
 LargeClass:
-  max_methods: 11  # TODO: decrease max_methods to 10-15 or less
+  max_methods: 14  # TODO: decrease max_methods to 10-15 or less
   exclude: []
   enabled: true
-  max_instance_variables: 2
+  max_instance_variables: 5
 UncommunicativeMethodName:
   accept: []
   exclude: []

data/lib/veritas/optimizer/algebra/difference.rb

@@ -58,7 +58,7 @@ module Veritas
           EmptyRight,
           LeftOrderOperand,
           RightOrderOperand,
-          MaterializedOperand,
+          MaterializedOperands,
           UnoptimizedOperands
         )
 

data/lib/veritas/optimizer/algebra/intersection.rb

@@ -58,7 +58,7 @@ module Veritas
           EmptyRight,
           LeftOrderOperand,
           RightOrderOperand,
-          MaterializedOperand,
+          MaterializedOperands,
           UnoptimizedOperands
         )
 

data/lib/veritas/optimizer/algebra/join.rb

@@ -7,6 +7,30 @@ module Veritas
       # Abstract base class representing Join optimizations
       class Join < Relation::Operation::Combination
 
+        CONTRADICTION = Veritas::Function::Proposition::Contradiction.instance
+
+      private
+
+        # Return the key to join the operations with
+        #
+        # @return [Header]
+        #
+        # @todo find a minimal key from the header
+        #
+        # @api private
+        def join_key
+          operation.join_header
+        end
+
+        # Return a predicate that matches every tuple in the materialized operand
+        #
+        # @return [Function]
+        #
+        # @api private
+        def materialized_predicate
+          matching_projection.reduce(CONTRADICTION) { |predicate, tuple| predicate.or(tuple.predicate) }.optimize
+        end
+
         # Optimize when operands' headers are equal
         class EqualHeaders < self
 
@@ -30,16 +54,108 @@ module Veritas
 
         end # class EqualHeaders
 
+        # Optimize when the left operand is materialized
+        class LeftMaterializedOperand < self
+
+          # Test if the left operand is materialized
+          #
+          # @return [Boolean]
+          #
+          # @api private
+          def optimizable?
+            left.materialized? && !right_matching_left?
+          end
+
+          # Return the join of the left and right with the right restricted
+          #
+          # @return [Algebra::Join]
+          #
+          # @api private
+          def optimize
+            operation.class.new(left, right.restrict { materialized_predicate })
+          end
+
+        private
+
+          # Test if the right operand is a restriction matching the left
+          #
+          # @return [Boolean]
+          #
+          # @api private
+          def right_matching_left?
+            right = self.right
+            right.kind_of?(Veritas::Algebra::Restriction) && right.predicate.eql?(materialized_predicate)
+          end
+
+          # Return a the matching projection of the materializd relation
+          #
+          # @return [Projection]
+          #
+          # @api private
+          def matching_projection
+            left.project(join_key)
+          end
+
+        end # class LeftMaterializedOperand
+
+        # Optimize when the right operand is materialized
+        class RightMaterializedOperand < self
+
+          # Test if the right operand is materialized
+          #
+          # @return [Boolean]
+          #
+          # @api private
+          def optimizable?
+            right.materialized? && !left_matching_right?
+          end
+
+          # Return the join of the left and right with the left restricted
+          #
+          # @return [Algebra::Join]
+          #
+          # @api private
+          def optimize
+            operation.class.new(left.restrict { materialized_predicate }, right)
+          end
+
+        private
+
+          # Test if the left operand is a restriction matching the right
+          #
+          # @return [Boolean]
+          #
+          # @api private
+          def left_matching_right?
+            left = self.left
+            left.kind_of?(Veritas::Algebra::Restriction) && left.predicate.eql?(materialized_predicate)
+          end
+
+          # Return a the matching projection of the materializd relation
+          #
+          # @return [Projection]
+          #
+          # @api private
+          def matching_projection
+            right.project(join_key)
+          end
+
+        end # class RightMaterializedOperand
+
         Veritas::Algebra::Join.optimizer = chain(
           EmptyLeft,
           EmptyRight,
           EqualHeaders,
           LeftOrderOperand,
           RightOrderOperand,
-          MaterializedOperand,
+          MaterializedOperands,
+          LeftMaterializedOperand,
+          RightMaterializedOperand,
           UnoptimizedOperands
         )
 
+        memoize :materialized_predicate
+
       end # class Join
     end # module Algebra
   end # class Optimizer

data/lib/veritas/optimizer/algebra/product.rb

@@ -62,7 +62,7 @@ module Veritas
           EmptyRight,
           LeftOrderOperand,
           RightOrderOperand,
-          MaterializedOperand,
+          MaterializedOperands,
           UnoptimizedOperands
         )
 

data/lib/veritas/optimizer/algebra/rename.rb

@@ -258,7 +258,18 @@ module Veritas
           #
           # @api private
           def optimize
-            operand.class.new(wrap_operand, operation.directions)
+            operand.class.new(wrap_operand, directions)
+          end
+
+        private
+
+          # Return the renamed directions
+          #
+          # @return [Relation::Operation::Order::DirectionSet]
+          #
+          # @api private
+          def directions
+            operand.directions.rename(aliases)
           end
 
         end # class OrderOperand