Feature proposal: Domain-based type mapping (boolean/guid) via connection string

[sencagri]

Feature Proposal: Domain-Based CLR Type Mapping (Opt-In)

Background

We’re currently migrating a production system from LCPI IBProvider (OleDb) to FirebirdSql.Data.FirebirdClient.

Our database makes heavy use of user-defined domains, for example:

• SMALLINT + CHECK → used as Boolean
• CHAR(16) CHARACTER SET OCTETS → used as Guid

With IBProvider, this works very nicely:

• It looks at RDB$FIELD_SOURCE
• Automatically maps domains to the correct CLR types (bool, Guid)

With the current .NET provider:

• Domain information is ignored

• We get:

  • SMALLINT → Int16
  • CHAR(16) → byte[]

This breaks quite a lot of things for us — especially data-binding and comparisons.

---

Real-World Situation

Our system is not small:

• 300+ tables
• Heavy use of Typed DataSet (ADO.NET)

Because of that, fixing this manually isn’t really an option:

• Changing generated DataSet types doesn’t scale
• Regeneration overwrites everything
• Maintaining custom mappings across hundreds of tables is fragile
• Adding a separate mapping layer would mean large refactoring

In short, without something at the provider level, migration becomes very difficult.

---

Why We’re Proposing This Upstream

We already implemented this on our side and it works well.

However, keeping it as a private fork is painful:

• We constantly need to rebase against upstream
• It adds maintenance overhead
• There’s always a risk of falling behind

By contributing this upstream:

• Others with similar domain-based schemas can benefit
• We don’t need to maintain a long-lived fork
• The feature can evolve together with the provider

---

Proposal

Add an opt-in domain-based mapping, configured via connection string.

Example:

boolean domains=D_BOOL%,IS\_%
guid domains=D_GUID%

How it works:

• Patterns use SQL LIKE syntax (%, _, \_)

• We match against RDB$FIELD_SOURCE

• If matched:

  • Boolean domains → returned as bool
  • Guid domains → returned as Guid

Important:

• The underlying data does not change
  (SMALLINT and CHAR(16) are still read/written as-is)
• This only affects the reported ADO.NET type
• Completely opt-in — no impact unless configured

---

Implementation

We already have a working implementation:

• DomainPatternList
  Handles LIKE-style pattern matching (case-insensitive, ignores RDB$*)

• DomainNameResolver
  Resolves and caches domain names per connection

• DbField changes

  • RawDbDataType → actual wire type
  • OverrideDataType → exposed type

• Connection string support

  • BooleanDomains
  • GuidDomains

---

Real Usage

We’re already using this internally and it made a big difference:

• Restores IBProvider-like behavior
• Removes the need for manual conversions
• Fixes data-binding and comparison issues
• Makes the migration manageable without large refactoring

---

Testing

• 12 integration tests
• Unit tests for pattern matching and parsing
• All existing tests pass

---

Compatibility

• No breaking changes
• Fully backward compatible
• Feature is strictly opt-in

---

Notes

We know the contribution guidelines suggest discussing first — that’s why we’re opening this before a PR.

We’re happy to adjust the design based on feedback.

---

Additional Context

We plan to keep using this provider long-term and are also open to becoming a project sponsor.

[cincuranet]

Thanks for the detailed write-up, but I don't think this fits the provider.

Typed DataSets are a legacy ADO.NET feature; building a domain-aware mapping subsystem into the core provider for that scenario isn't a direction I want to take.

The proposal only addresses the type reported for the schema. What about i.e. parameter binding? Or invalid conversions? Or people that don't (want to) use domains? Basically this feels like a leaky abstraction that will generate follow-up bug reports.

"Fixing this manually isn't really an option" isn't accurate - a one-off codegen/post-processing script over the DataSet's XML is a few hours of work at most and done. With zero ongoing provider coupling.

[sencagri]

Response to your concerns

I didn't see your response here so I have sent you an email about this issue, sorry for that. Thanks for taking the time to review this. I’ve opened a PR for easier code inspection.

Parameter binding

On parameter binding — it is handled, the proposal just didn’t show it clearly.

• DbField now separates:

  • RawDbDataType → the wire/SQL type (e.g. SMALLINT, CHAR(16) OCTETS)
  • DbDataType → the CLR-reported type (which returns the override when set)

• FbCommand routes all input values through:
  https://github.com/sencagri/NETProvider/blob/feature/domain-type-mapping/src/FirebirdSql.Data.FirebirdClient/FirebirdClient/FbCommand.cs#L1590

  This ensures:

  • bool parameters are converted to the correct numeric wire type (SMALLINT, INTEGER, BIGINT, etc.) based on RawDbDataType.

• Round-trip is covered by:

  • Write_BoolToSmallintRoundtrip
  • DataAdapter_BoolColumnRoundtrip

---

Leaky abstraction concern

The override is structurally prevented from reaching the protocol layer.

All wire paths now use RawDbDataType, including:

• GdsStatement.WriteRawParameter / ReadRawValue
• XsqldaMarshaler
• DbValue.GetBytes
• DbField.FixNull

The override exists only in:

• DbField.DbDataType → for ADO.NET reporting
• DbValue.GetValue → for GetBoolean() / GetGuid()

👉 Result:
A misconfigured pattern may produce a wrong reported CLR type, but cannot send incorrect bytes on the wire.

---

Invalid conversions

The conversion set is intentionally narrow:

• bool ↔ integer/decimal types
• Guid via CHAR(16) OCTETS (already supported path)

There is no general-purpose coercion.

Additionally:

• DbValue.GetBoolean was tightened:
  • Replaced Convert.ToBoolean
  • Now explicitly handles short/int/long/decimal → bool
  • Uses a culture-invariant fallback

👉 This ensures that even if a Boolean pattern is misapplied (e.g. to a BIGINT domain), it still returns a sane value instead of throwing.

---

Users who don't use domains

If no connection string keys are set:

• ConnectionString.HasDomainTypeMappings == false
• FbCommand.Prepare exits early
• No metadata queries (RDB$RELATION_FIELDS)
• No extra per-field state (OverrideDataType == null)
• CLR types remain identical to current master

👉 The feature is completely opt-in and dead code otherwise

Performance notes:

• Resolver uses one batched SELECT per unseen (relation, field) pair per connection
• Includes negative caching
• Avoids repeated metadata lookups

---

[deAtog]

@sencagri This is an interesting concept, but I think your implementation is poor. In my opinion it probably would have been better to create a separate provider that wraps the FirebirdSQL provider. A wrapper would be easier to extend to other providers in the future if needed rather incorporating these features into the FirebirdSQL provider directly. It would also be easier to maintain as your provider would only need to depend on the current FirebirdSQL provider rather than directly modifying it's behavior. I'm not a maintainer of this repository, this is just my opinion of how I would have implemented it.