Discussion: Additional Type Converters

[erikwrede]

In this repo, several issues and PRs propose adding additional Type Converters to natively support more PostgreSQL/Sqlalchemy[_utils] types in SqlAlchemyObjectTypes.

While most issues add support for types in libraries that are already included in dependencies, there is also a request to add additional dependencies to support even more types natively.

While I agree that adding extra types is beneficial, adding a new dependency to achieve that is problematic.

• geoalchemy2 support #140
• https://github.com/graphql-python/graphene-sqlalchemy/pull/274/files

These issues include the addition of a dependency to geoalchemy2.

I've opened this issue to hear other opinions about adding dependencies like geoalchemy. These issues include the addition of a dependency to geoalchemy2. Do the convenience benefits of not manually adding your type converters outweigh the disadvantages of increasing the number of dependencies? What about an additional types library, similar to SQLAlchemy_utils, just for the graphene-sqlalchemy types?

Additionally, I want to collect additional types that should be supported here. So far, the following PRs/Issues exist:

• How can I roll back after a database error? #293 (comment)
  Currently, sqlalchemy.types.Date and Time are converted to graphene.String instead of their graphene representation. If there is no blocker for that, this should be changed for the v3 release, since it contains breaking changes.

• https://github.com/graphql-python/graphene-sqlalchemy/pull/274/files
  Adding additional sqlalchemy_utils types

• Handle types.JSON and types.Variant #277
  JSON and Variant Type Support

• Map pg's uuid to graphene's uuid #203

• Postgres UUID Support

Notably, incompatibilities between sqlalchemy_utils and the Postgres types have been reported. Test cases should account for that:

• PostgreSQL specific fields (DATERANGE, TSTZRANGE, etc.) break when SQLAlchemy-Utils is installed #269

Another requested feature is the possibility of shadowing existing converters. This issue needs further discussion on how to implement it:

• Can a registered converter be shadowed to use a type other than a graphene type? #308

Due to the diversity of these requests, it would make sense to implement all the basic types in sqlalchemy_utils and sqlalchemy to avoid further issues. Let me know what you think!