2013/8/7 <[email protected]>
> Hi!
>
>
>> I didn't tried it on inserts/updates, selects are working fine
>>>
>>> well, some troubles arised here because of global registered converters.
> Because you are using Map<Class<?>, Converter<?, ?>>, where you register
> all of converters and you are using DataTypes.converter(field.getType())
> for finding right converter and because field.getTypes() returns simply
> scala.Option that's all works bad.
> So the main question - if I register converter on field definition level
> (and not globally, and I can do it because table definitions in scala way
> much more compact than java ones, and I often can write it without code
> generation), why you aren't using converter you actually have for this
> column? (in fact, you have Field<U> field parameter in static final <T, U>
> U getFromResultSet(ExecuteContext ctx, Field<U> field, int index), and it
> has a type of ConvertedDataType<T, U>, who can access actual converter
> passed to field constructor). I suppose you should use as more specific
> converter as you can - so, defined on field level, defined globally, or
> built-in.
>
Yes, not using the most specific converter for a given context is a
significant flaw in jOOQ's current data type converter support.
Specifically with the "generic type indirection" introduced by Option[T]
(instead of just plain T), the current converter support probably no longer
makes sense.
We could discuss, of course, if Option[T] is really such a clever solution
to the nullability problem in general. To me, nullability isn't really a
first-class citizen in a type system. It should be secondary with respect
to T. I wonder, how a library like jOOQ could reason about a type like
Option[T], once generics and the T type have been erased from the
information available to the java.lang.reflect package. But I guess that's
another story. :-)
To wrap things up, I'm afraid there's currently not much room for
improvement in that area, as thorough improvements lead to incompatible API
changes, which have to be postponed to jOOQ 4.0
Heh, I remember the discussions about using asterisks for imports in the
>> Java ecosystem. It is now well-agreed, that "global imports" aren't a good
>> idea, specifically because IDEs are good at automating the task of
>> importing single types and members. If you import org.jooq._, you
>> might also have lots of clashes with jOOQ's own, short type names, such as:
>> Condition, Configuration, DSL, Field, Row, Record, Result, Table...
>>
>> I'm actually a bit surprised by this feature, of being able to import
>> subpackages that way. That's just looking for trouble :-)
>>
>> Isn't there a better way to resolve such things? How do other libraries
>> deal with this? Or do you have an alternative suggestion? I'm not a fan of
>> using a "trick "package name to avoid problems with powerful (but
>> ambiguous) secondary-target languages. Can Scala imports rename imported
>> objects for their local scope, such as Ceylon can?
>>
>
> Well, simple client-side workaround is to import like this
> import org.jooq.{scala => scalajooq, _}
> But it's better to have ability to do import org.jooq._
>
OK, good to know there's a workaround. I will think about this in a broader
context for jOOQ 4.0, when some other package renaming will be done:
https://github.com/jOOQ/jOOQ/issues/2684
I still think that it is OK for a library to define its own sub-package
names. If users import everything, collisions are inevitable. Think about
importing:
import org.jooq._
import org.some.other.tool._
Both tools may have an impl package, and you'll run into the same issue
again. Again, in the Java ecosystem, IDE import automation has largely
rendered this problem obsolete. I'm positive that Scala-IDE will evolve
into a useful enough tool to auto-import explicit classes, instead of
letting users resort to importing "everything".
--
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.
