Hi Bill, Thanks a lot for the additional info!
2017-03-22 13:45 GMT+01:00 Bill O'Neil <[email protected]>: > 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. >> > > Here are some options I have come across relatively frequently. > 1. "snake_case" vs "camelCase" for field names > Yes, that eternal debate :) There are feature requests for that on the roadmap (even for RecordMapper) > 2. Including or excluding nulls / Optional.empty() > Null encoding is partially configurable in other serialisers, but I hadn't thought of excluding null attributes in JSON. Will definitely implement that: https://github.com/jOOQ/jOOQ/issues/6028 > 3. Formatting java.sql.Date, java.util.Date, java.time* as timestamps or > Strings with configurable formatters. > 4. Serializing an Enum as an Object when it has additional fields. > Absolutely. These will be part of https://github.com/jOOQ/jOOQ/issues/5673. We already have the appropriate type for this: Converter. We could register additional Converter<T, String> types, which implement serialisation (and optionally: deserialisation) logic for each column and/or data type. Deserialisation will be used in the Loader API, which can read the JSON / CSV / XML content. > I only bring it up because web services that expose different formats can > be extremely frustrating to work with. I do think you are right and if > someone needs more control they will just use RecordMappers. > I can feel the pain. Fun starts when something that is modelled as one value in one system needs to be split into two values in another system, and vice versa :) At some point, out-of-the-box functionality always breaks. But we can probably get quite far nonetheless. > 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... > > > Other potential non serialization issues. > 2. Validation - The existing POJO generation offers adding the validation > annotations. Although this might save time, I think validation is often > more complex than just matching the table constraints so it's probably not > very useful to keep. > Yes, I'm personally a bit disappointed by these features. I think the Hibernate people really pushed this in the recent past, but it's too simplistic, and probably not worth pursuing in jOOQ. Will definitely put this also on the deprecation candidate list. Thanks again for all your feedback! 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.
