Admitting I am not a Avaje Ebean expert or a JDBC expert either. I use play framework and Ebean in the "normal" use cases (H2 and mySQL basically) and they perform fine for me.
I found recently about the cassandra-jdbc driver project and was wondering if I could naively make them work together. So I tried and, once I turned off evolutions, I got a SQLFeatureNotSupportedException because cassandra-sql force autocommit always on.
I wanted to know if there is a way to make them work together since the driver claim to be Jdbc compliant and Ebean should be able to work with that. Is there something in the way Ebean use the drivers that make this impossible?
Although the cassandra-jdbc driver is jdbc complient, at the moment its not possible to use cassandra as the backend for your playframwork #Models.
There are a few projects trying to implement support for NoSql, although not explicitly cassandra, in the play framework, have a look at siena.
Also this SO question might be a useful reference.
Related
I want to use the JOOQ DSL in Quarkus to build my SQL (and hopefully execute them).
Therefore I added the following Quarkus JOOQ extension.
Since I want to use the reactive PG SQL Client in my project, I'm asking myself if e.g. the fetch() method of JOOQ will block the thread ? Is it compatible with the reactive vertx client under the hood or does it use a blocking one ? Looks like the latter one since it doesn't return a future or anything like that.
In that case I propably should only use JOOQ for creating the SQL string.
Which parts of the jOOQ API can be used reactively
jOOQ's ResultQuery<R> extends Publisher<R>, so you can just place a jOOQ query in any reactive stream implementation. There are 3 main Publisher subtypes in jOOQ:
ResultQuery<R> extends Publisher<R>
RowCountQuery extends Publisher<Integer>
Batch extends Publisher<Integer>
And starting with jOOQ 3.17, there will also be a way to create transactional Publisher types.
With this in mind, in the reactive world, you will never need to call any of the traditional jOOQ blocking execution methods. You'll always implicitly execute jOOQ queries via some reactive streams integration.
Avoiding calls to blocking API
Starting with jOOQ 3.17, all the blocking API (e.g. ResultQuery.fetch()) will be annotated as org.jetbrains.annotations.Blocking, so you get IDE support to warn you that you're about to do something that might not make sense in your non-blocking context.
Backing implementation
For any of this to work, you need to provide jOOQ with an R2DBC connection. R2DBC is an SPI that enables interoperability between client libraries like jOOQ and R2DBC drivers, like r2dbc-postgres. Just like JDBC, it works as an SPI, not strictly an API. Besides, it integrates also directly with the reactive streams SPI, which has been integrated in the JDK 9 via the Flow API.
There might be future work to support alternative non-blocking drivers in the future, however R2DBC seemed to be the most interoperable choice at the time the reactive support was added, and I do hope that the Vert.x and R2DBC teams will find ways to cooperate more tightly in the future. The Vert.x SQL client, for example, does not implement the reactive streams SPI directly, Red Hat does not seem too interested (yet) in moving forward with this issue here: https://github.com/eclipse-vertx/vertx-sql-client/issues/249
So, for now, this means that you have to either:
Use jOOQ with R2DBC, which is what jOOQ supports (not sure if Quarkus will support R2DBC, though I don't see any reason why it shouldn't)
Use jOOQ to generate SQL only and run the SQL with Vert.x (you'll lose a lot of type safety and convenience, as well as access to advanced features like MULTISET, which relies on jOOQ executing your query)
A side note on reactive execution
Of course, it's always important to think about whether you really need to go reactive. In my personal experience, this is mostly a matter of programming style, not actual performance and/or load requirements. Sticking with the blocking paradigm and JDBC will greatly simplify your every day work, and I doubt you'll notice a measurable difference in production.
I'm looking for a solution to do the same thing, I haven't tested it yet but I came across this repo:
https://github.com/jklingsporn/vertx-jooq
https://github.com/jklingsporn/quarkus-jooq-reactive-example
It may help to be fully reative using vert.x in quarkus.
Upon writing a DB-API interface, and a basic SQLAlchemy dialect for our database, I was assigned to pick up Java, and write a JDBC driver as well. I gather it'll be Level 4, with sockets against the database and such.
I know Zero Java. I intended to pick up Kotlin at some point, so I was wondering whether it'd be feasible to create a JDBC driver in Kotlin.
For example, as far as I know, Kotlin can use Java libraries. Not sure of the other way around - would any Java application be able to use a Kotlin JDBC driver, if written properly? What would be "properly" in this case? Other considerations to be noted?
Any feedback would be appreciated.
I also considered Jython, but I'm less inclined as I suspect it'll be less fitting, though not really sure on this one as well.
You can absolutely do this. JDBC driver vendors need to implement certain Java interfaces in package java.sql which is totally feasible with Kotlin as much as with Java. Just do it :)
You can get started with Driver
In my previous spring projects, I always use hibernate+postgresql to store the data. I rencently start to use spring-boot, and I am looking for a database system which allow me embed it in my project, without be required the installation of a external DBMS.
I try use SQLite, but in my searches I found some afirmations Hibernate isn't compatible with SQLite.
Anyone knows if this is possible and could point me a solution?
We've successfuly used HSQLDB with Hibernate for ages.
This is actually super cool for sales, you can demonstrate a working application on (potential) customers machine with the embedded HSQLDB database. And still be able to switch to "the real thing" later on.
See also this:
Does Hibernate Fully Support SQLite
and this:
https://code.google.com/p/hibernate-sqlite/
I am migrating Pro*COBOL and Pro*C (code with embedded SQL) to Java.
Am I right that I should move migrate all of the embedded SQL to JDBC calls?
Or is there a sort of "Pro*Java" way that Oracle would recommend? What is the usual best practice?
Yes.
There was (or is?) SQLJ for embedding SQL into Java, but I have never seen that in use anywhere.
Everything SQL-based in Java goes via JDBC.
A usual practice (not sure if a "best practice") is to abstract even further and use an ORM and some kind of persistence API.
As there is no easy way to migrate C or worse COBOL to Java you will be doing a lot of re-writing anyway. So using JDBC with your existing SQL is probably the easiest way to go.
Another poster mentioned SQLJ which is a possibility, however I don't think it really gains you anything as you will be doing so much re-factoring anyway, however if you are happy with the whole pre-compiler thing then it will work! (At least for Oracle or DB2, support is patchy for the freebie databases).
Does anybody has an experience with Spring Integration project as embedded ESB?
I'm highly interesting in such use cases as:
Reading files from directory on schedule basis
Getting data from JDBC data source
Modularity and possibility to start/stop/redeploy module on the fly (e.g. one module can scan directory on schedule basis, another call query from jdbc data source etc.)
repeat/retry policy
UPDATE:
I found answers on all my questions except "Getting data from JDBC data source". Is it technically possible?
Remember, "ESB" is just a marketing term designed to sell more expensive software, it's not a magic bullet. You need to consider the specific jobs you need your software to do, and pick accordingly. If Spring Integration seems to fit the bill, I wouldn't be too concerned if it doesn't look much like an uber-expensive server installation.
The Spring Integration JDBC adapters are available in 2.0, and we just released GA last week. Here's the relevant section from the reference manual: http://static.springsource.org/spring-integration/docs/latest-ga/reference/htmlsingle/#jdbc
This link describes the FileSucker with Spring Integration. Read up on your Enterprise Integration patterns for more info I think.
I kinda think you need to do a bit more investigation your self, or do a couple of tries on some of your usecases. Then we can discuss whats good and bad
JDBC Adapters appear to be a work in progress.
Even if there is no specific adapter available, remember that Spring Integration is a thin wrapper around POJOs. You'll be able to access JDBC in any component e.g. your service activators.
See here for a solution based on a polling inbound channel adapter too.