Hi James, Hmm, I'm not sure if this is a desireable approach for the jOOQ libraries. The recommended way to proceed here is to have this dependency tree :
your code + your generated code +-+ your converters +-- jooq your code generator +-+ your converters +-- jooq So, in other words, your converters should be built in their own, separate module that you can depend on from both your code and from your code generator. That seems to be the cleanest option in my opinion, unless I'm missing something? Cheers Lukas 2017-02-21 21:26 GMT+01:00 <[email protected]>: > Heya. > > I realize now that part of my problem is build dependency race conditions. > > I can't write Converter<JooqEnum, MyEnum> because our persistence > utilities live in a module that is built before the module which generates > jooq. > > The reasons for this are long and ugly, but suffice to say that in order > to share code with clients, and not have a totally hacked build, it has to > be this way > (we can't compile our DbGenerator with references to types that are > generated by the DbGenerator). > > What I wound up doing is writing a converter that resorts to some ugly > reflection to avoid the dependency on a type that does not exist yet: > > > public class VisibilityConverter<T extends EnumType> implements Converter<T, > Visibility> { > > private static class GeneratedTypeReflection { > > private final Lazy<Class<?>> cls; > private final Lazy<Method> valueOf; > > private GeneratedTypeReflection(String type) { > this.cls = > Lazy.deferredUnsafe(()->getClass().getClassLoader().loadClass(type)); > this.valueOf = > Lazy.deferredUnsafe(()->cls.get().getMethod("valueOf", String.class)); > } > } > > private final GeneratedTypeReflection type; > > public VisibilityConverter() { > type = new > GeneratedTypeReflection("com.redcurrent.data.sql.generated.enums.RcVisibility"); > } > > @Override > public Visibility from(T v) { > if (v == null) { > return null; > } > return Visibility.valueOf(v.getLiteral()); > } > > @Override > public T to(Visibility v) { > if (v == null) { > return null; > } > try { > return (T) type.valueOf.get().invoke(null, v.name()); > } catch (Exception e) { > throw new RuntimeException(e); > } > } > > @Override > public Class<T> fromType() { > return Class.class.cast(type.cls.get()); > } > > @Override > public Class<Visibility> toType() { > return Visibility.class; > } > > } > > Then standard custom converter / forced type semantics on the above > Visibility class. > > new ForcedType() > .withName(Visibility.class.getCanonicalName()) > .withExpression("visibility") > .withUserType(Visibility.class.getCanonicalName()) > .withConverter(VisibilityConverter.class.getCanonicalName()) > , > > > new CustomType() > .withName(Visibility.class.getCanonicalName()) > .withConverter(VisibilityConverter.class.getCanonicalName()) > > > It may be worthwhile to adopt this pattern into a Jooq > ReflectionEnumConverter which takes the fully qualified name of the > expected generated enum type; > I will likely make such an abstraction during code review, but thought I > would share in case others have issues with being able to reference the > jooq enum. > > -- > 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. > -- 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.
