Well, so far jOOQ plays very well with Ceylon, the only real issue I had is this identity constraint. I haven't tested tuple types yet, but Record1..Record22 seem to be sufficient for my needs. I made a little project named 'ceylon-jooq-adapter', for now it contains a naming strategy and custom data types converters that are suited for Ceylon, but I may try adding a custom code generator that replaces RecordN with tuples.
I also plan on writing a blog post on how to get started with Ceylon and jOOQ, I'll keep you updated here :) And of course, thanks for the feature request! Bastien Le lundi 24 août 2015 09:11:43 UTC+2, Lukas Eder a écrit : > > Hello Bastien, > > Thank you for your enquiry. > > A lot of API methods make use of java.lang.Number in jOOQ. For instance, > arithmetic operations such as sin(), cos(), or types such as > org.jooq.Sequence. So, perhaps you might run into issues at other locations > as well... > However, it's true that getIdentity() doesn't really have to make a > guarantee about its Identity's <T> type, given that Identity itself doesn't > impose any such bounds upon the <T> type. Besides, it should always be able > to match whatever <T> type bound that is generated by the code generator. > So it would indeed not be a bad idea to relax the bound of that return > type, even if that would constitute a backwards-incompatible change. > > I have registered a feature request for this: > https://github.com/jOOQ/jOOQ/issues/4488 > > Out of curiosity, how well does jOOQ play with Ceylon? I'm aware of > Ceylon's tuple types and I've discussed the possibility of record types in > Ceylon with Gavin in the past. Does that work well with jOOQ's > Record1..Record22 types, for instance? > > Cheers > Lukas > > 2015-08-23 23:08 GMT+02:00 <[email protected] <javascript:>>: > >> Hi, >> >> I'm trying to use jOOQ from Ceylon, so far it's been working quite well, >> except for identities. I used custom data types to substitute Java types >> with Ceylon types (e.g. int values will be mapped to >> ceylon.language.Integer instead of java.lang.Integer). The only problem >> I found is that in the generated code, getIdentity() forces me to use a >> type that extends java.lang.Number, which is not the case for >> ceylon.language.Integer. >> >> I removed the getIdentity() overrides in each generated class, and it >> worked until I tried to insert a record and retrieve a generated MySQL PK >> using returning(): if getIdentity() is not overridden, null is returned >> instead of the expected generated value. >> >> So, my question is: since jOOQ allows me to use virtually any custom data >> type I want, why do I *have to* use something that extends Number for >> identities? The only usage I found is in >> org.jooq.impl.AbstractDMLQuery.selectReturning(Configuration, >> Object...), but AFAICT this code is only setting values that are not >> necessarily Numbers, so it seems identities could be simplified to >> Identity<R, >> ?> instead of Identity<R, ? extends Number>. >> >> What do you think? >> >> -- >> 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/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.
