Hi,
I just wanted to point out that when using fetchInto(FOO), you'll
usually want to also do select(FOO.fields()) and avoid fetching all
the columns.
For example:
jooqContext.select()
.from(AUTHOR)
.join(BOOK).on(AUTHOR.ID.eq(BOOK.AUTHOR))
.where(BOOK.TITLE.eq("nightfall"))
.fetchInto(AUTHOR);
Will result in:
select author.id, author.first_name, author.last_name, book.id,
book.author, book.title from author join book on author.id =
book.author where book.title = ?
However:
jooqContext.select(AUTHOR.fields())
.from(AUTHOR)
.join(BOOK).on(AUTHOR.ID.eq(BOOK.AUTHOR))
.where(BOOK.TITLE.eq("nightfall"))
.fetchInto(AUTHOR);
Results in the more efficient:
select author.id, author.first_name, author.last_name from author join
book on author.id = book.author where book.title = ?
I'm guessing jooq could be improved to detect when too much data is
being fetched and thrown away from the database (in development, the
framework could keep track of which fields were eventually used and
log some kind of warning?).
Alok
On Wed, Apr 22, 2015 at 12:49 PM, Alok Menghrajani <[email protected]> wrote:
> Thanks for the quick response! I love that whenever I ask a question
> on this list I have a response waiting for me when I wake up.
>
> On Tue, Apr 21, 2015 at 11:21 PM, Lukas Eder <[email protected]> wrote:
>> [...]
>>
>> However, recursive generics are pandora's box that you generally don't want
>> to open, especially in a type hierarchy like that of Record. I've blogged
>> about this here:
>> http://blog.jooq.org/2013/06/28/the-dangers-of-correlating-subtype-polymorphism-with-generic-polymorphism/
>
> Great blog post, going to share it with my friends!
>
>> This will be addressed in jOOQ 4.0:
>> https://github.com/jOOQ/jOOQ/issues/2570
>
> :)
>
>> I suspect that by using a type similar to Optional<T>, we could properly
>> solve this. In fact, you could actually use Optional:
>>
>> Optional.of(record).map(myTypedMapper::map).get();
>>
>> // or:
>> Optional.of(record).map(r -> myTypedMapper.map(r)).get();
>
> This doesn't work, I might have gotten something wrong.
>
>> // or just plain old ;-)
>>
>> myTypedMapper.map(record);
>
> That's what I'm going to use for now.
>
>> A (silly) workaround would be to operate only with Result<R>, which doesn't
>> have this limitation.
>
> I thought about this for a little. I think you end up having to
> convert a list with zero or one elements (List<MyAuthor>) into a
> MyAuthor. It's not super elegant.
>
>> Interesting. Is there a reason why you didn't semi-join that relation, e.g.
>> via IN or EXISTS? Performance, perhaps?
>
> Thanks for pointing this out, I'll keep it in mind for the future.
> Right now, I'm converting jdbi code to jOOQ so I want to keep the same
> queries.
>
>> You're looking for Result.into(Table), or ResultQuery.fetchInto(Table):
>>
>> -
>> http://www.jooq.org/javadoc/latest/org/jooq/Result.html#into-org.jooq.Table-
>> -
>> http://www.jooq.org/javadoc/latest/org/jooq/ResultQuery.html#fetchInto-org.jooq.Table-
>>
>> You can use these methods with any query. It will produce records of type R
>> from Table<R>, containing only the columns of R, or null if the column name
>> wasn't present in the result.
>
> Thanks. fetchInto solves most of the issues I had and lets me use type
> safe mappers!
>
>> There had been a lot of bugs in the javac compiler that have all been fixed
>> in 1.8.0_40... I can't reproduce this particular one anymore, but I remember
>> having run into this kind of type inference problem with 1.8.0_25 and
>> earlier.
>
> Yes, some of my coworkers pointed out that it might be a compiler bug.
> I'm using 1.8.0_25, so things might be better once I upgrade.
>
> Alok
--
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.
