| Home >> All >> org >> apache >> derby >> iapi >> [ sql Javadoc ] |
• org.apache.derby.iapi.sql: Javadoc index of package org.apache.derby.iapi.sql.
Package Samples:
• org.apache.derby.iapi.sql.compile
• org.apache.derby.iapi.sql.conn
• org.apache.derby.iapi.sql.depend
• org.apache.derby.iapi.sql.dictionary
• org.apache.derby.iapi.sql.execute
Classes:
• DependencyManager: Dependency Manager Interface The dependency manager tracks needs that dependents have of providers. This is a general purpose interface interface which is associated with a DataDictinary object; infact the dependencymanager is really the datadictionary keeping track of dependcies between objects that it handles (descriptors) as well as prepared statements. The primary example of this is a prepared statement's needs of schema objects such as tables. Dependencies are used so that we can determine when we need to recompile a statement; compiled statements depend on schema objects like tables and constraints, ...
• TableDescriptor: This class represents a table descriptor. The external interface to this class is: external interface public String getSchemaName(); public String getQualifiedName(); public int getTableType(); public long getHeapConglomerateId() throws StandardException; public int getNumberOfColumns(); public FormatableBitSet getReferencedColumnMap(); public void setReferencedColumnMap(FormatableBitSet referencedColumnMap); public int getMaxColumnID() throws StandardException; public void setUUID(UUID uuid); public char getLockGranularity(); public void setTableName(String newTableName); public void setLockGranularity(char ...
• TriggerDescriptor: A trigger. We are dependent on TableDescriptors, SPSDescriptors (for our WHEN clause and our action). Note that we don't strictly need to be dependent on out SPSes because we could just disallow anyone from dropping an sps of type 'T', but to keep dependencies uniform, we'll do be dependent. We are a provider for DML (PreparedStatements or SPSes) The public methods for this class are: getUUID getName getSchemaDescriptor public boolean listensForEvent(int event); public int getTriggerEventMask(); public Timestamp getCreationTimestamp(); public boolean isBeforeTrigger(); public boolean isRowTrigger(); ...
• LanguageConnectionFactory: Factory interface for items specific to a connection in the language system. This is expected to be used internally, and so is not in Language.Interface. This Factory provides pointers to other language factories; the LanguageConnectionContext holds more dynamic information, such as prepared statements and whether a commit has occurred or not. This Factory is for internal items used throughout language during a connection. Things that users need for the Database API are in LanguageFactory in Language.Interface. This factory returns (and thus starts) all the other per-database language factories. ...
• Activation: An activation contains all the local state information necessary to execute a re-entrant PreparedStatement. The way it will actually work is that a PreparedStatement will have an executable plan, which will be a generated class. All of the local state will be variables in the class. Creating a new instance of the executable plan will create the local state variables. This means that an executable plan must implement this interface, and that the PreparedStatement.getActivation() method will do a "new" operation on the executable plan. The fixed implementations of Activation in the Execution impl ...
• ExecAggregator: An ExecAggregator is the interface that execution uses to an aggregate. System defined aggregates will implement this directly. The life time of an ExecAggregator is as follows. An ExecAggregator instance is created using the defined class name. Its setup() method is called to define its role (COUNT(*), SUM, etc.). Its newAggregator() method may be called any number of times to create new working aggregators as required. These aggregators have the same role and must be created in an initialized state. accumlate and merge will be called across these set of aggregators One of these aggregators will ...
• Statement: The Statement interface provides a way of giving a statement to the language module, preparing the statement, and executing it. It also provides some support for stored statements. Simple, non-stored, non-parameterized statements can be executed with the execute() method. Parameterized statements must use prepare(). To get the stored query plan for a statement, use get(). This interface will have different implementations for the execution-only and compile-and-execute versions of the product. In the execution-only version, some of the methods will do nothing but raise exceptions to indicate that ...
• ResultSet: The ResultSet interface provides a method to tell whether a statement returns rows, and if so, a method to get the rows. It also provides a method to get metadata about the contents of the rows. It also provide a method to accept rows as input. There is no single implementation of the ResultSet interface. Instead, the various support operations involved in executing statements implement this interface. Although ExecRow is used on the interface, it is not available to users of the API. They should use Row, the exposed super-interface of ExecRow. > Valid transitions: open->close close->open close->finished ...
• SPSDescriptor: A SPSDescriptor describes a Stored Prepared Statement. It correlates to a row in SYS.SYSSTATEMENTS. SYNCHRONIZATION : Stored prepared statements may be cached. Thus they may be shared by multiple threads. It is very hard for two threads to try to muck with an sps simultaeously because all ddl (including sps recompilation) clears out the sps cache and invalidates whatever statement held a cached sps. But it is possible for two statements to do a prepare execute statment at the exact same time, so both try to do an sps.prepare() at the same time during code generation, so we synchronize most everything ...
• RunTimeStatistics: A RunTimeStatistics object is a representation of the query execution plan and run time statistics for a java.sql.ResultSet. A query execution plan is a tree of execution nodes. There are a number of possible node types. Statistics are accumulated during execution at each node. The types of statistics include the amount of time spent in specific operations (if STATISTICS TIMING is SET ON), the number of rows passed to the node by its child(ren) and the number of rows returned by the node to its parent. (The exact statistics are specific to each node type.) RunTimeStatistics is most meaningful for ...
• ColumnDescriptor: This class represents a column descriptor. public methods in this class are: long getAutoincStart() java.lang.String getColumnName() DefaultDescriptor getDefaultDescriptor(DataDictionary dd) DefaultInfo getDefaultInfo UUID getDefaultUUID DataValueDescriptor getDefaultValue int getPosition() UUID getReferencingUUID() TableDescriptor getTableDescriptor DTD getType() hasNonNullDefault isAutoincrement setColumnName setPosition
• 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).
• DataDictionary: The DataDictionary interface is used with the data dictionary to get descriptors for binding and compilation. Some descriptors (such as table and column descriptors) are added to and deleted from the data dictionary by other modules (like the object store). Other descriptors are added and deleted by the language module itself (e.g. the language module adds and deletes views, because views are too high-level for modules like the object store to know about).
• ExecutionStmtValidator: An ExecutionStatementValidator is an object that is handed a ConstantAction and asked whether it is ok for this result set to execute. When something like a trigger is executing, one of these gets pushed. Before execution, each validator that has been pushed is invoked on the result set that we are about to execution. It is up to the validator to look at the result set and either complain (throw an exception) or let it through.
• ConglomerateDescriptor: The ConglomerateDescriptor class is used to get information about conglomerates for the purpose of optimization. NOTE: The language module does not have to know much about conglomerates with this architecture. To get the cost of using a conglomerate, all it has to do is pass the ConglomerateDescriptor to the access methods, along with the predicate. What the access methods need from a ConglomerateDescriptor remains to be seen.
• Dependency: A dependency represents a reliance of the dependent on the provider for some information the dependent contains or uses. In Language, the usual case is a prepared statement using information about a schema object in its executable form. It needs to be notified if the schema object changes, so that it can recompile against the new information.
• ExecutionFactory: This is the factory for creating a factories needed by execution per connection, and the context to hold them. There is expected to be one of these configured per database. If a factory is needed outside of execution (say, data dictionary or compilation), then it belongs in the LanguageConnectionContext.
• 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.
• ResultSetFactory: ResultSetFactory provides a wrapper around all of the result sets needed in an execution implementation. For the activations to avoid searching for this module in their execute methods, the base activation supertype should implement a method that does the lookup and salts away this factory for the activation to use as it needs it.
• Provider: A provider is an object that others can build dependencies on. Providers can themselves also be dependents and thus be invalid/revalidated in turn. Revalidating a provider may, as a side-effect, re-validate its dependents -- it is up to the implementation to determine the appropriate action.
• 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.
• ConstantAction: This interface describes actions that are ALWAYS performed for a Statement at Execution time. For instance, it is used for DDL statements to describe what they should stuff into the catalogs. An object satisfying this interface is put into the PreparedStatement and run at Execution time.
• Row: The Row interface provides methods to get information about the columns in a result row. It uses simple, position (1-based) access to get to columns. Searching for columns by name should be done from the ResultSet interface, where metadata about the rows and columns is available.
• 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.
• Dependent: A dependent has the ability to know whether or not it is valid and to mark itself as valid or invalid. Marking itself as invalid usually means it cannot be used in the system until it is revalidated, but this is in no way enforced by this interface.
| Home | Contact Us | Privacy Policy | Terms of Service |