Digest for jooq-user@googlegroups.com - 1 update in 1 topic

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Digest for jooq-user@googlegroups.com - 1 update in 1 topic

http://groups.google.com/group/jooq-user/topics mailing list
Lukas Eder <[hidden email]>: Nov 15 03:50PM +0100

Hi Pavel,
 
Thank you very much for your message, and for following up after your
tweets.
 
Indeed, PostgreSQL has quite a few interesting JSON(B) operators as well as
many other operators for its vendor-specific data types.
 
One of the problems with these things is that they are very poorly
standardised, and it will thus be rather difficult for jOOQ to standardise
on such an API. The other thing is the unfortunate choice of ascii
characters in PostgreSQL, which cannot be mapped easily to Java methods (in
Scala, it would be possible). Yes, there's always an ordinary function name
backing the implementation of such operators, but they're not really
idiomatic. This is just to give you a hint why we haven't done much in this
area yet.
 
Another problem with JSON is the fact that Java still doesn't have a
standard JSON binding API, akin to JAXB for XML. We could pick an arbitrary
3rd party dependency (we won't) or roll our own (we shouldn't). So, it's
not easy to move forward, here.
 
More comments inline:
 
2017-11-14 14:38 GMT+01:00 Pavel Finkelshtein <[hidden email]>
:
 
> I think it would make sense to implement some type of sub-dsl for work
> with JSON values, like GSON's one: asJsonObjetc, asJsonArray and so on.
 
Absolutely, such a sub-dsl would be quite nice. We already have a few
methods in PostgresDSL, mainly for array support. But again, JSON is more
difficult to standardise.
 
Nothing will keep you from publishing your own third-party mini-dsl on
GitHub, though! :) We'll certainly help promote it.
 
 
> developers ability to work with json fields almost like with related
> tables. Moreover, it will be possible to make updates to sub-entities and
> then update whole entity without performing ultra-complex queries!
 
I'm aware of that tool. It's definitely out of scope for jOOQ to integrate
with such third party tools (and maintain the integration). But again,
nothing keeps you from rolling your own!
 
This is not to say that such an integration wouldn't make sense in jOOQ.
But given the cost / benefit ratio (including the ratio of maintaining such
a solution in the long run), I just prefer to invest a bit more in other
features first...
 
Thanks,
Lukas
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to [hidden email].