Hello,
The logical syntax may be useful here:
Result<BookRecord> bookRecords=jooq.from(BOOK)
.join(AUTHOR).on(BOOK.AUTHOR_ID.eq(AUTHOR.ID))
.where(AUTHOR.NAME.eq("Victor Hugo"))
.select(BOOK) // Meaning select book.*
.fetch();
Since select() is close to fetch(), it may be easier to keep type
information.
Is there a technical reason (in API design or whatever) preventing logical
syntax?
It's only an idea, probably a blind one.
Gérald
Le dimanche 1 décembre 2013 15:16:08 UTC+1, Lukas Eder a écrit :
>
> Hi Aurélien,
>
> Aha, I can see the point of confusion. The problem here is that jOOQ
> currently doesn't really support selecting t.*. By writing
> select().from(t.join(u).on(...)), you're implicitly selecting t.*, u.*. Now
> even if jOOQ checked the explicit projection at runtime to see if t.* is
> being completely selected, this would not lead to generic typesafety in
> Java, thus you'd still get a Result<Record> or maybe, a
> Result<Record[N]<T1, T2, ..., T[N]>>
>
> In other words, this is an API limitation / flaw of jOOQ. I currently
> don't know how this could be resolved. As always, I'm very open to
> suggestions.
>
> Cheers
> Lukas
>
> 2013/11/30 Aurélien Manteaux <[email protected] <javascript:>>
>
>> Hi Lucas,
>>
>> I don't understand when you say that once you join other table the
>> specific table type would get lost.
>> For example :
>> - SELECT t.* FROM Table1 t => the result type is Table1
>> - SELECT t.* FROM Table1 t JOIN Table2 k ON t.id=k.tid => the result
>> type is still Table1
>>
>> Am I missing something ?
>>
>> Cheers,
>>
>> Aurélien
>>
>> On Saturday, November 16, 2013 12:03:45 PM UTC+1, Lukas Eder wrote:
>>
>>> Hi Gérald,
>>>
>>> 2013/11/16 Gérald Quintana <[email protected]>
>>>
>>> Hello,
>>>>
>>>> Actually, the question was: why can't I use joins when using selectFrom
>>>> statement?
>>>>
>>>
>>> Hmm, yes, I was going to explain that but somehow I forgot...
>>>
>>> The idea is simple (although debatable). The idea behind selectFrom() is
>>> to provide jOOQ with a clearly defined record type, which may be a more
>>> specific type than for instance Record2<Integer, String>. Once you join
>>> other tables, that specific table type would get lost (i.e. denormalised).
>>> Since selectFrom() offers no way to redefine the projection (SELECT
>>> clause), the result would inevitably be the type-unsafe Record.
>>>
>>> There's certainly room for API improvement in that area. I'm open to
>>> suggestions.
>>>
>>> At first, I thought that "selectFrom(SOURCE).fetchInto(TARGET)" meant
>>>> "insert into TARGET (...) select .. from SOURCE".
>>>>
>>>
>>> Aha. No that would be insertInto(TARGET).select(...)
>>>
>>> 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] <javascript:>.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>
--
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/groups/opt_out.
