This version (2017/05/27 13:44) is a draft.
Approvals: 0/1

[12:06:24] <aesteve> hi temporalfox, pmlopes !

[12:06:29] <aesteve> how are you ? :)

[12:06:39] <pmlopes> hi @aesteve

[12:06:44] <pmlopes> fine and you?

[12:06:52] <aesteve> fine too, thanks

[12:07:17] <aesteve> I was doing a very interesting experiment and wanted to share/discuss resutls with you

[12:08:01] <aesteve> Use case : an API returning JSON, from many (something like 8) SQL tables through an optimized query

[12:08:10] <aesteve> implementation 1 : Vert.x + pure JDBC

[12:08:24] <aesteve> implementation 2 : JPA (Hibernate) mapping

[12:08:49] <aesteve> the generated SQL query by Hibernate is strictly the same as the one in pure JDBC

[12:09:16] <aesteve> ~50ms for the request

[12:09:27] <aesteve> Vert.x avg response time : 55ms

[12:09:47] <aesteve> Tomcat + Spring + JPA avg response time : 300ms

[12:11:35] <aesteve> most of the time seems to lie within the ORM mapping onto collections

[12:12:18] <aesteve> but the JPA request creation is way more developper-friendly (through the criteria API)

[12:12:49] <aesteve> thus I was wondering, if there was a solution to take advantage of best of both worlds

[12:13:25] <temporalfox> aesteve hi

[12:13:34] <aesteve> i.e. : create the query through JPA + criteria API, then compile it (AST ⇒ row SQL) and execute it through JDBCClient

[12:13:53] <aesteve> and then avoid the mapping

[12:14:00] <aesteve> I guess this could be non-blocking

[12:14:19] <pmlopes> humm then you would be creating a new ORM yourself

[12:14:26] <temporalfox> @aesteve going to have lunch :-)

[12:14:35] <aesteve> the ORM part, yes

[12:14:49] <aesteve> I mean the “unmarshalling” part of the ORM

[12:14:54] <pmlopes> with all the complications of supporting all vendors etc… it would be some work…

[12:15:30] <aesteve> I'm not sure actually, I'll let the ORM generate the SQL query (and thus dealing with vendors, I guess)

[12:15:53] <aesteve> the only part I'd need would be the “reverse” mapping of JDBC results onto objects

[12:16:07] <temporalfox> @aesteve @pmlopes I think one thing is to look at existing projects and see if there are parts that are reusable

[12:16:21] <aesteve> (actually the results would be JsonObject / JsonArray if executed through Vert.x)

[12:16:34] <aesteve> temporalfox: do you have some in mind ?

[12:17:03] <aesteve> I tried to look for such projects but didn't find any that just generates SQL and lets you deal with it

[12:17:08] <aesteve> JOOQ maybe

[12:18:24] <aesteve> anyway, just to let you guys know I'm currently trying to address this issue, if you ever ear someone working on such a project ;)

[12:19:24] <aesteve> bon app[unknown:eacute]tit temporalfox

[12:21:46] <Sticky_> well if you are looking specificly at the deserialization part (which you seem to think is the bottle neck), you can look at

[12:24:23] <aesteve> thanks Sticky_

[12:28:34] <pmlopes> personally i don't like sql code generators since for example there are really powerful tools in SQL like CTE, window functions and so forth that you cannot map from hibernate/jpa or it takes more code and makes it really unreadable compared to the original sql code.

[12:28:49] <pmlopes> bu there are many dsl's for sql out there such as:

[12:29:01] <pmlopes> or jooq as someone said before

[12:29:35] <aesteve> I found the octo dsl

[12:30:34] <aesteve> but the “6 years ago” scared me a little

[12:32:04] <aesteve> The two things I'd like to have would be : the JPA metamodel kindof (typesafe queries) + the automatic “DTO” mapping onto receiver objects

[12:32:53] <aesteve> (to execute some business logic for instance)

[12:34:14] <pmlopes> so you're looking for something like:

[12:34:19] <aesteve> I'm not a huge fan of sql generators, too. But having a programmatic way to add joins, (if(http.contains(field)) { sql.join(table);)

[12:35:17] <pmlopes> where you can mix JSON with some business logic on the receiver object

[12:35:56] <aesteve> thanks for your implementation

[12:36:11] <aesteve> that may do what I want to

[12:36:17] <aesteve> (for the deserialization part)

[12:39:09] <aesteve>

[12:39:19] <aesteve> res1.result().close() ?

[12:39:26] <pmlopes> take it with a grain of salt because i was just experimenting with a way of working with any backend sql, redis, mongo, if you say i want sql stuff can be optimized

[12:39:50] <aesteve> yeah sure, don't worry

[12:41:13] <pmlopes> yeap it is buggy ;) probably more things like that are missing

[12:41:33] <aesteve> no problem :)

[12:41:48] <aesteve> it's probably worth contributing actually

[12:44:42] <aesteve> going to eat, thanks a lot for your feedback pmlopes !!