Module: DataMapper::Adapters

Defined in:

lib/data_mapper/adapters/data_object_adapter.rb,
lib/data_mapper/adapters/sql/quoting.rb,
lib/data_mapper/adapters/sql/coersion.rb,
lib/data_mapper/adapters/mysql_adapter.rb,
lib/data_mapper/adapters/sqlite3_adapter.rb,
lib/data_mapper/adapters/abstract_adapter.rb,
lib/data_mapper/adapters/postgresql_adapter.rb,
lib/data_mapper/adapters/sql/mappings/table.rb,
lib/data_mapper/adapters/sql/mappings/column.rb,
lib/data_mapper/adapters/sql/mappings/schema.rb,
lib/data_mapper/adapters/sql/commands/load_command.rb,
lib/data_mapper/adapters/sql/mappings/associations_set.rb

Overview

An Adapter is really a Factory for three types of object, so they can be selectively sub-classed where needed.

The first type is a Query. The Query is an object describing the database-specific operations we wish to perform, in an abstract manner. For example: While most if not all databases support a mechanism for limiting the size of results returned, some use a “LIMIT” keyword, while others use a “TOP” keyword. We can set a SelectStatement#limit field then, and allow the adapter to override the underlying SQL generated. Refer to DataMapper::Queries.

The final type provided is a DataMapper::Transaction. Transactions are duck-typed Connections that span multiple queries.

Note: It is assumed that the Adapter implements it’s own ConnectionPool if any since some libraries implement their own at a low-level, and it wouldn’t make sense to pay a performance cost twice by implementing a secondary pool in the DataMapper itself. If the library being adapted does not provide such functionality, DataMapper::Support::ConnectionPool can be used.

Defined Under Namespace

Modules: Sql Classes: AbstractAdapter, DataObjectAdapter, MysqlAdapter, PostgresqlAdapter, Sqlite3Adapter