Why must identity use a Number?

[jansen....@gmail.com]

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?

[Lukas Eder]

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

--
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 jooq-user+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[jansen....@gmail.com]

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

[Lukas Eder]

2015-08-24 11:26 GMT+02:00 <jansen....@gmail.com>:

I also plan on writing a blog post on how to get started with Ceylon and jOOQ, I'll keep you updated here :)

Wonderful, looking forward to reading that!

Cheers,

Lukas

[Bastien Jansen]

Here it is: http://bjansen.github.io/ceylon/2015/08/24/ceylon-plus-jooq-equals-heart.html

[Lukas Eder]

That was quick! :)

Thank you very much for your nice words in the article.

Very interesting bit about the \i prefix. That's a bit of a quirk indeed. Do you know the background of Ceylon's requiring attributes to start with a lower-case letter? What are upper-case letters reserved for?

An interesting bit would be to implement Ceylon source code generation, the way we have done for Scala, before. We know whether columns are nullable, so we could perhaps generate the "?" on each type to indicate whether the column is indeed nullable. I wonder if that will work from an interoperability perspective - it would certainly add lots of value to the Ceylon integration. I have created a feature request for a CeylonGenerator:

https://github.com/jOOQ/jOOQ/issues/4497

It would also handle the \i issue by using a different default for the generator strategy - and perhaps by generating Ceylon types instead of java.lang types.

Some of those findings are definitely worth being referenced from the jOOQ manual in a new jOOQ+Ceylon section. I have registered an issue for this:

https://github.com/jOOQ/jOOQ/issues/4496

In any case, thanks a lot for this write-up! This is very insightful. Looking forward to hearing further feedback from you :-)

Cheers,

Lukas

[Bastien Jansen]

As a matter of fact, I already started writing a custom generator that overrides bits of the Java generator, but I quickly ran into major problems. Those problems are related to Ceylon's Java interoperability, for example I get errors when I override TableImpl, stating that some abstract methods are not correctly implemented, while in fact they are. Also, I had errors while calling super constructors, but once again it's a problem on our side. I'll submit this to the Ceylon team and see if it can be fixed.

If I can get interesting results, I may submit a pull request in the future ;-).

Regarding \i, basically uppercase identifiers are for types (classes, interfaces, type parameters), while lowercase is for values (objects, functions, parameters, variables etc). Ceylon tries very hard to have a syntax as regular as possible, so enforcing those constraints helps a lot, unfortunately it can be a little annoying when using Java code...

You received this message because you are subscribed to a topic in the Google Groups "jOOQ User Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jooq-user/uPBvwmx-IQQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jooq-user+...@googlegroups.com.

[Lukas Eder]

2015-08-25 14:08 GMT+02:00 Bastien Jansen <jansen....@gmail.com>:

As a matter of fact, I already started writing a custom generator that overrides bits of the Java generator, but I quickly ran into major problems. Those problems are related to Ceylon's Java interoperability, for example I get errors when I override TableImpl, stating that some abstract methods are not correctly implemented, while in fact they are. Also, I had errors while calling super constructors, but once again it's a problem on our side. I'll submit this to the Ceylon team and see if it can be fixed.

Hmm, interesting. I suspect there are quite a few of these interoperability caveats. We've seen similar things in the Scala ecosystem, where protected static methods couldn't be called from subclasses...

If Ceylon can't make this work, we're very open to changes to internal API, just let us know.

If I can get interesting results, I may submit a pull request in the future ;-).

Sounds like a plan!

Regarding \i, basically uppercase identifiers are for types (classes, interfaces, type parameters), while lowercase is for values (objects, functions, parameters, variables etc). Ceylon tries very hard to have a syntax as regular as possible, so enforcing those constraints helps a lot, unfortunately it can be a little annoying when using Java code...

OK, I see. Well, luckily, at least the DSL is written all in camelCase as any proper Java API.

Cheers,
Lukas