Differences

This shows you the differences between two versions of the page.

Link to this comparison view

irc:1473804000 [2017/05/27 13:44] (current)
Line 1: Line 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 https://​github.com/​eishay/​jvm-serializers/​wiki
 +
 +[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: https://​github.com/​octo-technology/​java-sql-dsl
 +
 +[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: https://​github.com/​pmlopes/​v-odm
 +
 +[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>​ https://​github.com/​pmlopes/​v-odm/​blob/​master/​src/​main/​java/​com/​jetdrone/​odm/​backend/​JdbcMapper.java#​L73-L92
 +
 +[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 !!