2015-04-13 22:39 GMT+02:00 Ed Erwin <[email protected]>:
>
> OK. That sort-of works and I may do it. It is necessary to also suppress
> "SuspiciousToArrayCall"
>
That appears to be a vendor-specific suppression. IntelliJ?
> When I have to tell the compiler to suppress three warnings for a one-line
> command, I feel like I'm doing something fishy.
>
Yes.
> Unfortunately, ... there is no way to overload based on the generic type
>> parameter of the collection. I.e. the following is not possible:
>>
>> public static <T1, T2, T3> Table<Record3<T1, T2,
>> T3>> values(Collection<Row3<T1,T2,T3>> rows) {}
>>
>>
> Actually, I think that *is *possible. My IDE, and standard JRE compiler
> allows it. Inside the DSL class you could have a method like this:
>
> public static <T1, T2, T3> Table<Record3<T1, T2, T3>>
> values(Collection<Row3<T1, T2, T3>> rows) {
> return new Values<Record3<T1, T2, T3>>(rows.toArray(new
> Row3[rows.size()])).as("v", "c1", "c2", "c3");
> }
>
Then, you should switch IDEs and compilers. :)
The existing methods are these:
public static <T1, T2> Table<Record2<T1, T2>> values(Row2<T1, T2>... rows)
public static <T1, T2, T3> Table<Record3<T1, T2, T3>> values(Row3<T1, T2,
T3>... rows)
Overloading is possible, because generics are irrelevant here. The erased
argument types differ: Row2[], Row3[]. When you do this, however:
public static <T1, T2> Table<Record2<T1, T2>> values(Collection<? extends
Row2<T1, T2>> rows)
public static <T1, T2, T3> Table<Record3<T1, T2, T3>> values(Collection<?
extends Row3<T1, T2, T3>> rows)
... then, the erased argument types don't differ. They're 2x Collection.
Hence, this kind of overload is illegal. Consider also JLS §8.4.2:
http://docs.oracle.com/javase/specs/jls/se8/html/jls-8.html#jls-8.4.2.
(§8.4.2 is actually not the formal reason for this, I'll look it up later)
javac 1.8.0_40 yields:
[ERROR]
C:\Users\Lukas\workspace\jOOQ\jOOQ\src\main\java\org\jooq\impl\DSL.java:[331,58]
error:
name clash: <T1#1,T2#1,T3>values(Collection<Row3<T1#1,T2#1,T3>>) and
<T1#2,T2#2>values(Collection<Row2<T1#2,T2#2>>) have the same erasure
You would need to have a series of such methods for "Collection<Row1>" ....
> "Collection<Row22>", but that is no different than the current situation
> with a bunch of methods for "Row1[]" ... "Row22[]".
>
Yes - it is different. That's why we chose to support only varargs/arrays
in this case, not collections of rows. Which is again why you're running
into this whole issue here.
> In my own code, I avoid java array types, and varargs, exactly because of
> the incompatibility of arrays and generics. Using the Collection interface,
> or the ArrayList implementation, instead of arrays allows better use of
> generics.
>
I understand that and we're doing the same whereever possible. When a
collection of Type[N] arguments is passed, overloading for the various
values of [N] (1..22) is possible only for arrays, not for
java.util.Collection
> Anyhow, passing large amounts of data to SQL using "values" turns out to
> be not efficient.
>
Yes, this is only worthwhile for small amounts of data. In the past (at
least in Oracle), temporary tables and batch insertion have never let me
down for this kind of use case.
--
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.
