apicurio-registry
apicurio-registry copied to clipboard
Apicurio
Support for other SQL storage database flavours than just PostgreSQL
Although I see PostgreSQL as a good first choice, it would be good to also support other relational databases, such as SQLServer, Oracle, ...
Is that already on your mind, or would you accept a contribution?
Hi @gschmutz We don't plan to add support for another relational database in the near future. Contributions would be welcome, but we would like to keep the number of persistence options on a maintainable level.
I agree with @jsenko - we always welcome contributions. I think Oracle and SQLServer are good additions. If you would like to contribute, I'm happy to point out where the gotchas might be lurking (if needed). :)
@jensko & @EricWittmann thanks for your answer and sorry that it took a few days to reply. Maybe let me also quickly explain the reason for us to be in favour of SQLServer as an addl storage option. We are using Apicurio Registry in a Azure setup, where we treat Azure Event Hub as if it was a Kafka cluster (using the Kafka API Azure offers), and Apicurio Registry with the confluent-compliant API allows us to use all the tools we are used from working with a plain Kafka and Confluent Schema Registry setup (including the option to later replace Azure Event Hub with a "real" Kafka managed service). Because Azure Event Hub does not support Log Compacted Topics, using the Kafka storage is not an option. That's why Apicurio registry is a perfect fit, as it allows us to use DB as a storage option, but of course with Azure, using SQL Server as the DB is a more natural fit. Will see if I can contribute SQLServer or even Oracle as well. Just had a quick view on the Postgres implementation, but have to do a more deep dive before I might have some questions.
OK thanks for the context, @gschmutz ! I don't think supporting SQL Server should be very difficult. There should only be a relatively small number of SQL queries that may need to be TSQL (or whatever SQL Server calls their flavor). Most of our queries are very standard. I would point you to the H2 and PG subclasses of the SqlStatements interface:
https://github.com/Apicurio/apicurio-registry/blob/master/app/src/main/java/io/apicurio/registry/storage/impl/sql/H2SqlStatements.java
https://github.com/Apicurio/apicurio-registry/blob/master/app/src/main/java/io/apicurio/registry/storage/impl/sql/PostgreSQLSqlStatements.java
One major thing to mention is that Quarkus handles the database type at build time. So in addition to code changes, we'll also likely need another container image to be built. I don't think we can re-use the existing SQL based container image, as that is PG specific.
What do you think, @famartinrh ?
yep, I agree with Eric, it's shouldn't be difficult to add support for other SQL databases. And yep, we will need to build another container image but using quarkus drivers for the new target SQL db.
Contributions are always welcome! We are happy to provide help and guidance to contributors!
Hi all, we have a need for SQLServer support in our organization. If nobody's working on it, I could make it happen (hopefully). Please ping me here if you already have something. /cc @vsevel
@matthyx at the end we went forward using PostgreSQL and didn't work on the SQLServer support.
@matthyx at the end we went forward using PostgreSQL and didn't work on the SQLServer support.
Ok, thanks for your reply. I'll wait few days for others to report (eventually) and then will see how we can do it.
As far as I know there isn't anyone working on sqlserver support. We'd obviously love a contribution. :)
As far as I know there isn't anyone working on sqlserver support. We'd obviously love a contribution. :)
Good, I'll speak to my manager and try to work on that in a few days...
Looks great! Reviewed and commented. Just one small thing/question before merging. Nice work.