Net4x.DapperLibrary.Postgres 1.9.9

DapperLibrary.Postgres

PostgreSQL provider integration for DapperLibrary. This project supplies a Postgres-specific DapperContext implementation, a provider factory backed by Npgsql, and Postgres-specific database model and type mappings.

Purpose

Provide PostgreSQL engine-specific behavior while preserving the common DapperLibrary API. This includes:

• PostgresDapperContext � a DapperContext configured for Npgsql with Use / UseOnce helpers.
• NpgsqlProviderFactory � configures parameter handling and adapter events for the Npgsql provider.
• PostgresDatabaseModel, PostgresDatabaseModelTypes and PostgresDatabaseEnumTypes � identifier delimiters, statement terminator, parameter naming and SQL type mappings for PostgreSQL.

Key types

• PostgresDapperContext

  • Derives from DapperContext and initializes the context with NpgsqlProviderFactory and configuration from DapperConfigurationManager.
  • Static helpers Use, Use(IContextCreator), Use(string, string) and UseOnce integrate with DapperContextFactory and set common Postgres defaults (for example identity initializer and datetime formatting).
  • When used via Use helpers, contexts are configured with:
    • DatabaseModel.IdentityInitializer = "GENERATED ALWAYS AS IDENTITY"
    • DatabaseModel.FormatDatetimeAsString = dateTime => $"TIMESTAMP '{dateTime:yyyy-MM-dd HH:mm:ss.fff}'"

• NpgsqlProviderFactory

  • Inherits from ProviderFactoryBase and uses NpgsqlFactory.Instance as the underlying provider.
  • Sets ParameterModel.ParameterPrefix = "@" and ParameterModel.AddIndex = true and installs a PrepareCommandParameters delegate.
  • Attaches RowUpdating / RowUpdated handlers to data adapters and exposes hooks to forward these events.

• PostgresDatabaseModel and related types

  • Identifier delimiters: " (double-quote).
  • Statement terminator: ;.
  • Parameter prefix: @ and parameter base name: Par.
  • Type mappings reflect PostgreSQL types: uuid, jsonb, timestamptz, bytea, numeric, double precision, integer, bigint, boolean, etc.

Usage examples

Create and use a Postgres context directly:

using var context = new PostgresDapperContext();
// use context.Operations / context.Schema / context.SaveDataTable etc.

Register a context creator in bootstrap code:

PostgresDapperContext.Use();

// or bind an explicit connection string and provider name
PostgresDapperContext.UseOnce(connectionString, providerName);

When creating contexts via the static helpers, the database model will be pre-configured with Postgres-friendly defaults for identity columns and datetime literal formatting.

Multi-targeting & compatibility

• The project is built to be compatible with .NET Standard (the current build artifacts are produced for .NET Standard targets in this repository). Consumer projects targeting modern .NET (5/6/8/10) or .NET Framework should reference the matching compiled asset from the package.
• Conditional compilation and provider selection logic in the wider solution ensure the appropriate ADO.NET provider (Npgsql) is referenced for the target framework used by the consumer.

Synchronous vs asynchronous behavior

• PostgreSQL (Npgsql) offers robust async I/O support. DapperLibrary exposes both synchronous and asynchronous variants for most operations (GetDataReaderAsync, GetDataTableAsync, SetDataAsync, QueryAsync<T>, etc.).
• Prefer the Async-suffixed methods in server and I/O-bound applications to avoid blocking threads. The library uses async provider APIs where available and falls back to synchronous flows on frameworks/providers that lack Task-based ADO.NET async support.

Events and data adapter behavior

• NpgsqlProviderFactory.CreateDataAdapter wires RowUpdated and RowUpdating events coming from NpgsqlDataAdapter and forwards them via the provider factory. This enables consumer code to hook into the DbDataAdapter row lifecycle when using SaveDataTable and related adapter-based persistence.

Notes and best practices

• Use WithConnection overloads when executing operations against a different named connection for a single call to avoid race conditions around ConnectionStringToRead.
• Prefer Use / UseOnce helpers to ensure consistent Postgres configuration across created contexts.
• Rely on the schema helpers (IDapperContext.Schema) and cached metadata for efficient schema inspection.

For implementation details, consult the source files under DbContexts and the NpgsqlProviderFactory class.