Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for R2DBC #83

Open
avinash-anand opened this issue Jul 27, 2020 · 4 comments
Open

Support for R2DBC #83

avinash-anand opened this issue Jul 27, 2020 · 4 comments

Comments

@avinash-anand
Copy link

Hi Team,

I would like to request a feature for support of postgis data-types for R2DBC driver.
For background - below are the issues and discussion on the r2dbc driver repo :

Please let me know if I can help in some way in this ?

cc: @mp911de

@phillipross
Copy link
Contributor

Thanks for submitting this issue @avinash-anand

This looks like a worthy usecase for one of the architectural goals of this project to create an easier way to build codecs for specific usecases. Currently the project allows JDBC users to read/write postgis database datatypes using either the "classic" geometry types that are native to this project, and/or use JTS geometry types from the JTS project. The mechanism that controls which java types are used is a "wrapper" for the postgis jdbc driver since this project pre-dates the java service loader framework. One of the goals of this project is rework this wrapping mechanism and replace it with a more modern approach. An approach based on a service loader mechanism and codecs makes the most sense and is planned for the next major version (no ETA yet).

While it would be possible to write specific codecs with the current codebase, it would be better to use the new version which won't require the sacrifices of maintaining backward compatibility.

Collaborating on this project and contributing ideas, code etc would be the obvious way to help move things forward.

@avinash-anand
Copy link
Author

Thanks for your comments @phillipross .

While it would be possible to write specific codecs with the current codebase, it would be better to use the new version which won't require the sacrifices of maintaining backward compatibility.

Does this mean, a new major version of this repo or you mean some new repository?

Collaborating on this project and contributing ideas, code etc would be the obvious way to help move things forward.

Please let me know what changes do you expect initially and I can try to raise some PRs on that lines.

@mp911de
Copy link

mp911de commented Jul 28, 2020

FWIW, r2dbc-postgresql exposes a CodecRegistry SPI that allows for registration of codecs to read and write custom types supporting both, text and binary representations. Extensions can easily integrate by following Java ServiceLoader conventions and the driver picks up extensions from the class path.

@phillipross
Copy link
Contributor

Does this mean, a new major version of this repo or you mean some new repository?

New major version of this repo would be preferred. This would actually be a combination of changes, starting with the versioning scheme 😄

Please let me know what changes do you expect initially and I can try to raise some PRs on that lines.

There's initially some infrastructure work that needs to be done to get this repo in shape. I'd just been waiting for some hint of community interest before actually moving forward in order to justify the effort. You can simply watch this repo and chime in whenever you'd like, submit ideas or feedback, ask questions of the existing codebase, or whatever else you'd like.

And thank you @mp911de for the extra information. I did browse the r2dbc-postgresql project and immediately recognized the alignment with codec registry 😉

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants