You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe
When using R2DBC drivers in the context of a object-mapping framework, it's desirable to distinguish between simple types (R2DBC/driver primitives) and complex types (user-types).
Right now, R2DBC defines a set of primitives (Java primitives, several JSR-310 types). Additionally, each driver may define its own primitive types (e.g. Postgres with Json and Geo types, MySQL with BitSet and java.time.Year, SQL Server with BigDecimal/BigInteger, PostGIS with additional Geo types, and so on).
While the majority of used types map to R2DBC spec types that can be generally considered simple types, driver-specific types require maintenance by object-mapping library maintainers to catch up with what happens in the driver space.
Describe the solution you'd like
Ideally, R2DBC drivers report their supported simple types that can be natively interchanged with the database through some sort of API.
The type system of several databases can be dynamic which requires interaction with the database to determine the effective typeset. In most cases, integrations are configured with a ConnectionFactory that holds the configuration. Once configured, a ConnectionFactory typically does not change its config which could make it a source for type details. With the assumption of ConnectionFactoryMetadata being not tied to database interaction, ConnectionFactory doesn't seems a good fit, though.
Connection already exposes ConnectionMetadata that may contain details retrieved from the actual database connection. We could extend ConnectionMetadata with a default method that does not break implementations:
An interface along the lines of the following example could serve the purpose:
public interface ConnectionMetadata {
String getDatabaseProductName();
String getDatabaseVersion();
/**
* Returns a collection of types that are natively supported by the driver to represent database values.
*/
Collection<Class<?>> getNativeTypes(); // getSimpleTypes(), getValueTypes()
}
The actual method name to be discussed.
Describe alternatives you've considered
Manual registration in the object mapping framework. This is a tedious effort to keep up with driver changes.
Feature Request
Is your feature request related to a problem? Please describe
When using R2DBC drivers in the context of a object-mapping framework, it's desirable to distinguish between simple types (R2DBC/driver primitives) and complex types (user-types).
Right now, R2DBC defines a set of primitives (Java primitives, several JSR-310 types). Additionally, each driver may define its own primitive types (e.g. Postgres with
Json
and Geo types, MySQL withBitSet
andjava.time.Year
, SQL Server withBigDecimal
/BigInteger
, PostGIS with additional Geo types, and so on).While the majority of used types map to R2DBC spec types that can be generally considered simple types, driver-specific types require maintenance by object-mapping library maintainers to catch up with what happens in the driver space.
Describe the solution you'd like
Ideally, R2DBC drivers report their supported simple types that can be natively interchanged with the database through some sort of API.
The type system of several databases can be dynamic which requires interaction with the database to determine the effective typeset. In most cases, integrations are configured with a
ConnectionFactory
that holds the configuration. Once configured, aConnectionFactory
typically does not change its config which could make it a source for type details. With the assumption ofConnectionFactoryMetadata
being not tied to database interaction,ConnectionFactory
doesn't seems a good fit, though.Connection
already exposesConnectionMetadata
that may contain details retrieved from the actual database connection. We could extendConnectionMetadata
with adefault
method that does not break implementations:An interface along the lines of the following example could serve the purpose:
The actual method name to be discussed.
Describe alternatives you've considered
Manual registration in the object mapping framework. This is a tedious effort to keep up with driver changes.
Teachability, Documentation, Adoption, Migration Strategy
Update the specification with the interface definition.
The text was updated successfully, but these errors were encountered: