Motivation

To allow a client to set the size of the fetch array an FDO provider will use when executing a query.

Overview

For queries that return a large number of objects many feature sources support improving performance by configuring the row fetch size in order to reduce the number database server round trips required to satisfy the selection criteria. For example, Oracle and Microsoft SQL Server support fetching many rows at once.

While many FDO providers take advantage of this internally, the fetch size they use is fixed and does not allow the caller to tune it based on their circumstances. This enhancement will allow callers to tune the fetch size for providers that will support this. Providers that do not use a fetch size or have a fixed internal implementation simply will ignore the set fetch size. In either case, this does not affect the actual results of queries as it is a performance tuning parameter.

Proposed Solution

The FdoISQLCommand and FdoIBaseSelect interfaces will also be extended to add the following two new methods to get/set fetch size.

/// \brief
/// Gets the fetch size of the data set when executing query against
/// the underlying data store. This parameter is typically set in
/// situations where large amount of data are expected when a query
/// is executed and providers need to minimize the number of returned data.
/// For example, fetch 100 rows in one execution step.
///
/// \return
/// Returns the fetch size.
///
FDO_API virtual FdoInt32 GetFetchSize() = 0;
/// \brief
/// Sets the fetch size of the data set when executing query against
/// the underlying data store. This parameter is typically set in
/// situations where large amount of data are expected when a query
/// is executed and providers need to minimize the number of returned data.
/// For example, fetch 100 rows in one execution step.
///
/// \param value
/// Input the fetch size.
///
/// \return
/// Returns nothing.
///
FDO_API virtual void SetFetchSize(FdoInt32 fetchSize) = 0;

Managed FDO API

The FDO Managed Interfaces will be updated in a similar manner to reflect the proposed changes.

Provider Implementation

Initially, we need this for our Autodesk providers and applications. An empty default implementation will be added so that this change will not materially affect other providers and does not entail work for people other than Autodesk. Other provider developers can add it and use it as needed.