>
> 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 2. Including or excluding nulls / Optional.empty() 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. 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. 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. 1. Caching - Attached records might cause issues when caching the results from a query in memory. I think there are enough work arounds by either using RecordMappers or detached Records where it shouldn't be a concern. 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. Personally I would see myself using DSLContext directly with RecordMappers over using the Records directly, just personal preference. POJO generation is a convenience that jOOQ currently offers but that doesn't mean it belongs in jOOQ. I can auto generate POJOs in my IDE, or write my own generator. I don't see any reason why POJOs couldn't also be deprecated. Bill On Wed, Mar 22, 2017 at 6:46 AM, Lukas Eder <[email protected]> wrote: > Hi Ben, > > Thanks for sharing your thoughts! > > 2017-03-21 21:11 GMT+01:00 <[email protected]>: > >> I never found the DAOs and Pojos useful and disabled code generating >> them. In the past, I was also concerned that they'd promote an ORM world >> view, leading to requests for JPA, rather than embracing SQL. >> > > Well... no, we won't :) > > I prefer to use DSLContext directly and never heard a complaint (only >> praise) from coworkers when they used jOOQ. I sometimes use the record >> types, but only for internal logic. Instead I use jsonSchema2Pojo (or in >> the past, protobuf) to generate my service types. >> > > Oh, interesting, I wasn't aware of this website / library. One would wish > we had a more formal JSON binding API like JAXB with XJC, though... :) Then > again, one would wish for a more formal JSON schema specification like XSD. > > But oh well. That discussion is something entirely else... > > The fetchInto() mapping is usually enough and when not the custom mapping >> is pleasant enough. I've often written custom repositories to extract the >> query logic from the services to simplify the code. But when the class is >> well factored, like a background job, I'm more inclined to embed the query >> rather than bloat a repository with one-off usages. >> >> I can understand why some would want to use the Pojo codegen and return >> the results directly. To me that couples the service schema to the data >> schema, which may only match one-to-one early on. By having a service >> schema its easier to refactor and be less likely to break the external >> contract by mistake. The amount of work to write a schema, e.g. json >> schema, is trivial and it is nice to know exactly what the payload looks >> like and, optionally, run it through a validator. >> >> These days I use a hybrid nosql / sql data model in Postgres, resulting >> in a high usage of json schema for generation the UI and dynamically >> configuring a backend processing pipeline. If I had started with DOAs then >> I'd have needed to move away regardless. >> > > I think that last sentence wraps it up very nicely. Unlike a lot of other > jOOQ features, this one is an "early prototype" one. Perhaps that's OK if > some third-party library did it (e.g. a hypothetical > github.com/use-jooq-for-trivial-apps), but not for the core library. > > Thank you very much for your confirmation! > Lukas > > -- > You received this message because you are subscribed to a topic in the > Google Groups "jOOQ User Group" group. > To unsubscribe from this topic, visit https://groups.google.com/d/ > topic/jooq-user/-LnkZtUTb3c/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- 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.
