Home >> All >> org >> apache >> derby >> iapi >> sql >> [ compile Javadoc ]

• org.apache.derby.iapi.sql.compile: Javadoc index of package org.apache.derby.iapi.sql.compile.


Package Samples:

• org.apache.derby.iapi.sql.compile

Classes:

• Parser: The Parser interface is intended to work with Jack-generated parsers (now JavaCC). We will specify "STATIC=false" when building Jack parsers - this specifies that the generated classes will not be static, which will allow there to be more than one parser (this is necessary in a multi-threaded server). Non-static parsers do not have to be re-initialized every time they are used (unlike static parsers, for which one must call ReInit() between calls to the parser).
• RequiredRowOrdering: This interface provides a representation of the required ordering of rows from a ResultSet. Different operations can require ordering: ORDER BY, DISTINCT, GROUP BY. Some operations, like ORDER BY, require that the columns be ordered a particular way, while others, like DISTINCT and GROUP BY, reuire only that there be no duplicates in the result.
• C_NodeTypes: The purpose of this interface is to hold the constant definitions of the different node type identifiers, for use with NodeFactory. The reason this class exists is that it is not shipped with the product, so it saves footprint to have all these constant definitions here instead of in NodeFactory.
• JoinStrategy: A JoinStrategy represents a strategy like nested loop, hash join, merge join, etc. It tells the optimizer whether the strategy is feasible in a given situation, how much the strategy costs, whether the strategy requires the data from the source result sets to be ordered, etc.
• CompilerContext: CompilerContext stores the parser and type id factory to be used by the compiler. Stack compiler contexts when a new, local parser is needed (if calling the compiler recursively from within the compiler, for example).
• ExpressionClassBuilderInterface: This is a simple interface to hide the impl of ExpressionClassBuilder from the protocol side. RESOLVE - This interface needs to be filled in and the impl code changed to go through the interface as much as possible.
• Optimizer: Optimizer provides services for optimizing a query. RESOLVE: o Need to figure out what to do about subqueries, figuring out their attachment points and how to communicate them back to the caller.
• CostEstimate: A CostEstimate represents the cost of getting a ResultSet, along with the ordering of rows in the ResultSet, and the estimated number of rows in this ResultSet.
• OptimizablePredicateList: OptimizablePredicateList provides services for optimizing a table in a query. RESOLVE - the methods for this interface need to get defined.
• OptimizerFactory: This is simply the factory for creating an optimizer. There is expected to be only one of these configured per database.
• NodeFactory: This is an interface for NodeFactories. There is expected to be only one of these configured per database.
• AccessPath: AccessPath represents a proposed access path for an Optimizable. An Optimizable may have more than one proposed AccessPath.
• OptimizableList: OptimizableList provides services for optimizing a list of Optimizables (tables) in a query.
• CodeGeneration: This is a simple interface that houses externally visible statics for code generation.
• TypeCompiler: This interface defines methods associated with a TypeId that are used by the compiler.
• RowOrdering: This interface provides a representation of the ordering of rows in a ResultSet.
• Visitor: A visitor is an object that traverses the querytree and performs some action.
• OptimizablePredicate: OptimizablePredicate provides services for optimizing predicates in a query.
• Optimizable: Optimizable provides services for optimizing a table in a query.
• Visitable: A Visitable is something that can be visited by a Visitor
• TypeCompilerFactory: Factory interface for the compilation part of datatypes.

Home | Contact Us | Privacy Policy | Terms of Service