Independent and Dependent Layers

The dbstreams library is really two layers: the database-independent part, and the database-dependent part.

The independent part is the stream layer. It defines the public interface used by applications. It has no knowledge of what kind of server or native library is used to communicate with the server. The stream layer concentrates instead on implementing the stream metaphor.

The provider layer is database-dependent. It "generifies" the native database library, providing a uniform interface for use by dbstreams.

What does "generify" mean? It means to create a uniform way to:

"Generification" features

• Describe a user or account

• Connect to a server

• Send a query

• Insert and Extract data

• Handle errors

• Manage the stream state

Easier said than done. Server implementations and native client libraries vary in the way the define users, databases, datatypes, and errors. Certainly the primary challenge in the design of the provider interface is define all those things uniformly, such that no information is lost and no idiosyncrasies are passed.

Before a dbstream can be used (and normally at construction) the application passes a token (of type provider_type) designating the provider to be used. [1] The dbstream class instantiates the appropriate provider, storing its address in provider *pprovider. All providers are derived from provider, which defines storage for some member variables and defines the calling interface as a set of pure virtual functions.