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 <[email protected]> : > 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. > Regarding 3rd point of my tweet, JSON introspection. I think that it may > be possible to convert JSON to Records, by using this > <http://www.jsonschema2pojo.org/> project. Of course, generated source > will need some corrections, according to Record semantics, but it will give > 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 message because you are subscribed to the Google Groups "jOOQ User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
