2018-05-30 16:28 GMT+02:00 Nicolai Ehemann <[email protected]>:
> Hi Lukas,
>
> thank you for your answer (and sorry for taking so long to come back to
> this).
>
> On Wednesday, May 9, 2018 at 11:38:30 AM UTC+2, Lukas Eder wrote:
>>
>> I don't see the value of additional API at this point. The logic you
>> mentioned is still reasonable but either the example was incomplete, or
>> there is a subtle bug. An alternative would be to take all columns, put
>> them in a list, and call contains on it:
>>
> You are right; the example is wrong. In my use case, I have in fact a
> table with constant values of different types that is referenced from other
> tables, sometimes multiple times (for different types). The problem occurs
> when there are more than two references, but the select statement does not
> include the join for one of them. Then, the code above raise the warning,
> as the remaining two are seen as possible candidates.
>
Aha, I see. Along the lines of:
SELECT x.id, x1.text, x2.text, x3.text
FROM x
JOIN x_lookup x1 ..
JOIN x_lookup x2 ..
JOIN x_lookup x3 ..
And now you're omitting one of the joins (e.g. x3) but still referencing
the column in the SELECT clause (e.g. x3.text), which is then accidentally
mapped to one of the others.
Then, I definitely think my most recent suggestion will be optimal:
Arrays.asList(record.fields()).contains(B.B_ID)
>>
>>
>> This will definitely work around any potential ambiguity issues and focus
>> only on calling equals() on each field in the record.
>>
> This indeed works nicely. It is also quite readable; although it's
> probably not the best option performance-wise.
>
Why wouldn't it be? Let's look at the Arrays$ArrayList.contains()
implementation:
@Override
public int indexOf(Object o) {
E[] a = this.a;
if (o == null) {
for (int i = 0; i < a.length; i++)
if (a[i] == null)
return i;
} else {
for (int i = 0; i < a.length; i++)
if (o.equals(a[i]))
return i;
}
return -1;
}
@Override
public boolean contains(Object o) {
return indexOf(o) != -1;
}
That's about as fast as it gets, right?
> It would still be more readable and would provide for an optimized
> implementation if there was:
>
> record.containsFields(B.B_ID)
>
We could discuss readability of course. I have a different opinion here,
because the API is already quite bloated, every new option will in fact
contribute to more confusion, so we must be careful about adding things.
Regarding optimisation, I don't see how such an implementation could be
more optimal than the other one. Are you worried about the Arrays$ArrayList
allocation? It is likely eliminated by escape analysis... The loop itself
is optimal.
--
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.
