>
> Oh, interesting, so you extended the jOOQ records with lazy loading
> capabilities? :) OK, that wouldn't work then.
>
It was a Scala / Slick project and it made some sense for that specific
model. Most of the code did not operate that way :). The connection caused
a few headaches although most of them just pointed out our bugs in the
request lifecycle.
1. jOOQ implements better serialisation capabilities (e.g. jOOQ 3.10
> Record.formatJSON())
> 2. A better intermediary is used (e.g. java.util.Map)
> 3. etc.?
>
This could work just as well. I personally like POJO generation but it
probably wouldn't be much work for me to handle that myself if I really
needed it.
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). 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?.
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.
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).
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.
Bill
On Tue, Mar 21, 2017 at 12:19 PM, Lukas Eder <[email protected]> wrote:
>
>
> 2017-03-21 15:16 GMT+01:00 Bill O'Neil <[email protected]>:
>
>> Samir's use is exactly how I use the generated POJOs.
>>
>> Or does the fact that it is still "attached" bother you?
>>
>>
>> This bothers me a little but can be worked around. I ran into some
>> complications doing something similar in a previous project. The issue we
>> ran into was some values were lazily loaded and the model was passed into
>> our JSON serializer AFTER the connection was closed causing exceptions. I'm
>> not sure if the same issue would arise here but its nice working with plain
>> POJOs and knowing it won't be an issue. Also as Samir mentioned it can mess
>> with serializers.
>>
>
> Oh, interesting, so you extended the jOOQ records with lazy loading
> capabilities? :) OK, that wouldn't work then.
>
>
>> That doesn't mean jOOQ should be responsible for such conveniences.
>> However, if POJO generation was still supported you could also keep the
>> RecordMapper generation to avoid reflection and do something like this.
>>
>>
>> UserPojo user = getPojo();
>>
>> create.executeInsert(UserPojo.mapper().map(user));
>> // Alternate API?
>> create.executeInsert(user, UserPojo::mapper);
>>
>> user = create.selectFrom(Tables.USER).where(Tables.USER.ID.eq(1L)).
>> fetchOne(UserPojo::mapper);
>>
>> RecordMappers could be in new classes instead of the DAO, as static
>> fields / methods to the POJOs, or part of the generated Tables.
>>
>> Just a thought.
>>
>
> Yeah, indeed. Although again, I'm not sure if we'd just be moving an
> unnecessary feature elsewhere rather than scratching the actual itch. If
> the POJO is used almost uniquely as an intermediary for a serialisation
> library, then something's not right. Better solutions would include:
>
> 1. jOOQ implements better serialisation capabilities (e.g. jOOQ 3.10
> Record.formatJSON())
> 2. A better intermediary is used (e.g. java.util.Map)
> 3. etc.?
>
> I guess, this will need some further thought... But generated POJOs *and*
> RecordMappers seem to go the wrong direction, in my opinion... (I remember
> the discussion, though)
>
> --
> 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.
