2017-03-21 18:45 GMT+01:00 Bill O'Neil <[email protected]>: > > I could see JSON having endless opinionated debates around snake case vs > camel case, including or excluding nulls in the JSON, etc (Look at all of > the Jackson configuration options). >
Indeed! We're going that way, too :) https://github.com/jOOQ/jOOQ/issues/5372 JSON, XML, and CSV import and export are very useful jOOQ features, so there's definitely room for improvement here. For instance, jOOQ 3.9 allows for both array-of-array [[1,2,3],[4,5,6],[7,8,9]] and array of object [{"a":1,"b":2,"c":3},{"a":4,"b":5,"c":6},{"a":7,"b":8,"c":9}] result formats. jOOQ 3.10 further expands on this. We'll continue to take feature requests to see what else users want here. ... it's not like serialising a Result / Record to JSON is black magic. There aren't too many options for these data types. > I think Record.formatJSON() will be extremely beneficial but might not > solve the web service requirements. Users probably already have a preferred > serializer configured with their preferences. Maybe an option would be to > have contributors create 3rd party jooq-jackson, jooq-gson Record > serializers?. > One per JSON library? There are so many :) I'm pretty sure that in the case of JSON, we'll be able to tackle all the hurdles of "customisation" eventually (if the serialisation is 1:1, otherwise, users will use RecordMappers anyway). > java.util.Map could be a good intermediary. > > I'm not sure how this would work with something like Swagger but I believe > it would solve the Jackson issues. As always bear with me on naming. Assuming > we have a user table (id, email). > > interface UserView { > void setId(Long value); > Long getId(); > void setEmail(String value); > String getEmail(); > } > > // generated > public class UserRecord extends UpdatableRecordImpl<UserRecord> > implements Record2<Long, String>, *UserView* { > ... > *public* *UserView **view() {* > * detach(); // could or would this be a good / bad idea?* > * return this;* > * }* > * ...* > } > > Or if you wanted records could extend interface Viewable<T> { T view() }. > Obviously not a good name especially in regards to SQL. > We already have the IUserRecord interface generation, and the detach call could be achieved by using the Settings.attachRecords = false... But I'm not sure if this is going in the right direction... I don't like the idea of encoding some implied knowledge of specific third party libraries into jOOQ. > I think most reflection should play nicely with this unless they are being > overly aggressive and grabbing internal states. It gets rid of the > intermediate objects and overhead creating them. Is effectively the same as > a POJO. It would add a single method to each record and not alter the API > other than that (maybe add some override annotations). > But in most cases, there's really no need for a nominal type (I know, Java is obsessed with nominal typing), but a Record is ultimately just a tuple with attribute names. Serialisation libraries should be able to serialise such types IMO. Map is one of the simplest encodings of a tuple in the JDK... > After writing I realize this will only work well for serializing and not > deserializing unless there is a way to convert it back to a UserRecord > which could require "attaching". I'll leave it in case it generates any > ideas but currently I don't think its a viable solution. > You can auto-attach records after deserialisation by using RecordListener. It's possible with ExecuteListener as well. Or, you can use Record.from(Object) (back to reflection). Anyway, my lesson here in the context of the deprecation discussion is: POJOs are sometimes a useful workaround for certain serialisation topics. If we invest more into serialisation, this use-case will be weakened eventually, and we might no longer need to generate POJOs - from this point of view. We'll probably see other points of view... Cheers, 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.
