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.
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:
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!
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.
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:
https://github.com/graphql-python/graphene-sqlalchemy/issues/293#issuecomment-1111502105 Currently,
sqlalchemy.types.DateandTimeare converted tographene.Stringinstead 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
https://github.com/graphql-python/graphene-sqlalchemy/pull/277 JSON and Variant Type Support
https://github.com/graphql-python/graphene-sqlalchemy/pull/203
Postgres UUID Support
Notably, incompatibilities between sqlalchemy_utils and the Postgres types have been reported. Test cases should account for that:
Another requested feature is the possibility of shadowing existing converters. This issue needs further discussion on how to implement it:
Due to the diversity of these requests, it would make sense to implement all the basic types in
sqlalchemy_utilsandsqlalchemyto avoid further issues. Let me know what you think!