[ANNOUNCEMENT] Work on jOOQ 3.0 has begun

[Lukas Eder]

Dear community,

The recently released version 2.6.0 is probably the last minor release
on the 2.x version stream. The time has come to move on to the next
major step, jOOQ 3.0. Important features of the 3.0 major release will
include:

- Improved Record type-safety through row value expressions
- Improved Factory / Configuration API through clean separation of
query building and query execution
- Improved thread-safety (hopefully)
- Improved code generator, which should be more extensible (possibly
based on Aaron Digulla's suggestions)
- A cleaner "classic" API (as opposed to the DSL API)
- Experimentation with more advanced JPA annotations support when
mapping Record into POJOs
- Experimentation with Scala 2.10 Macros
- Removal of all deprecated things
- Lots of minor improvements to the API

For more details about what is currently being planned, please
consider the relevant milestone on GitHub:
https://github.com/jOOQ/jOOQ/issues?milestone=17

Also, feel free to suggest major improvements that should be
implemented in a major release. Now is the time!

Do note that if you're building jOOQ directly from GitHub master, you
may find some API instability in the next couple of months.

This release currently has no due date. I expect to have a first
release candidate ready by the end of December 2012, though

Cheers
Lukas

[Lukas Eder]

Hi Stéphane,

> I would have loved to see this one :
> https://github.com/jOOQ/jOOQ/issues/1629

Yes, these features will be addressed in jOOQ 3.0. I forgot to mention
this specific one.

> For people not relying on some container for transaction management, it
> would save a lot of code.
> I often find myself testing autocommit state to know whether I should start
> and commit/rollback a new transaction or just let the caller take care of
> it.
> Best

Yes. Also the usage of DataSources along the lines of distributed
transactions (i.e. closing pooled connections after usage) does not
necessarily work well for developers who do not rely on containers.

I'm hoping to generally improve that area in 3.0

Cheers
Lukas

[Stéphane Cl]

Hello,

Excellent news!

Yes, I had a look at the code a while ago before I started using jooq, Connections obtained from datasources were proxied to close automatically, unfortunately that wasn't very suitable for JDBC-style transaction scenarios.
I chose to use jooq because I was growing tired of ORMs, frameworks, POJO domain models, 7-layer java cake designs and all those over-engineering practices that are so common in the java world nowadays so I'd like to avoid relying on containers. Of course I can live with Connection based factories but I am not against a nicer way to manage transactions ;-). 

Thanks for all your work Lukas!
Best

[Lukas Eder]

> Of course I can live with Connection based factories
> but I am not against a nicer way to manage transactions ;-).

Let's see if going into transaction-business is a little plus for
jOOQ, or if I'm opening pandora's box :-)

> Thanks for all your work Lukas!

You're welcome

Cheers
Lukas

[Adam Gent]

Hey Lukas since your starting work on jOOQ 3.0 I thought you might want to look at my project I finally released today.

I promised you a while back that I would do this :) 

https://github.com/agentgt/jirm

Obviously its not as mature or as advance as jOOQ. 

It also has a different goal of jOOQ of which is to be an ORM for immutable objects.

I have added many feature I have always wanted like SQL Placeholder Templates that you can copy and paste  into any SQL Query tool and then copy them back:

https://github.com/agentgt/jirm/tree/master/jirm-core

Looking forward to jOOQ 3.0!

Cheers

-Adam

[Lukas Eder]

Hello Adam,

> Hey Lukas since your starting work on jOOQ 3.0 I thought you might want to
> look at my project I finally released today.

Yes, I've seen your first release. Congratulations to that! I'll
certainly have a look and steal 1-2 ideas ;-)

> Obviously its not as mature or as advance as jOOQ.
> It also has a different goal of jOOQ of which is to be an ORM for immutable
> objects.

Immutability can be a great feature if you design your application
around that. I'll be curious how that is received. Eventually, I'll
write a short promotional article about JIRM on my blog, which is
republished on DZone

> I have added many feature I have always wanted like SQL Placeholder
> Templates that you can copy and paste into any SQL Query tool and then copy
> them back:
> https://github.com/agentgt/jirm/tree/master/jirm-core

Interesting. I wonder how SQL templating of that sort will work, once
SQL statements get more complex. Do you support /* ... */ style
comments, too? I've recently had a look at Stephen Colebourne's
(JodaTime) SQL templating solution, where he wrote a little external
DSL for precisely that purpose:
http://blog.joda.org/2012/10/elsql-librarydsl-to-manage-sql.html

I can see that those templating engines, such as myBatis, ElSql, JIRM
work well in an entire problem domain...

> Looking forward to jOOQ 3.0!

Me too! :-)
Thanks for your feedback and for the promotion of JIRM. If you have
any other good ideas that you put in JIRM and that you want to
discuss, feel free to mention them on this group as well

Cheers
Lukas

[Adam Gent]

Yeah I was going to put in "/* ...  */" support but it ended up making the SQL nastier than just forcing you to put the placeholder at the end of the line

plus I don't think all databases support "/* ... */". At some point I will probably add it though.

Most of the time for SELECT statements I don't need that many placeholders replaced (1-3 on average).

Where it can get nasty is on INSERT and UPDATE statements but for those statements you can use the auto ORM JPA SQL generation.

To tell you the truth I actually like the tedium of new lines and having to format your SQL.

I'm sure you have written INSERT statements where its difficult to match up which value goes to which column.

For example this is tedious for short INSERTs:

INSERT INTO test_bean 

(string_prop, long_prop, timets)

VALUES (

'HELLO' -- {stringProp}

, 3000 -- {longProp}

, now() -- {timeTS}

)

But for really long inserts with many columns its actually convenient.

[Stéphane Cl]

Hi,

On Sunday, November 4, 2012 4:26:59 PM UTC+1, Adam Gent wrote:

Yeah I was going to put in "/* ...  */" support but it ended up making the SQL nastier than just forcing you to put the placeholder at the end of the line

plus I don't think all databases support "/* ... */". At some point I will probably add it though.

Most of the time for SELECT statements I don't need that many placeholders replaced (1-3 on average).

Where it can get nasty is on INSERT and UPDATE statements but for those statements you can use the auto ORM JPA SQL generation.

To tell you the truth I actually like the tedium of new lines and having to format your SQL.

I'm sure you have written INSERT statements where its difficult to match up which value goes to which column.

The idea of real SQL queries and placeholder parameters sound very nice imho. It would also open the way to POJO generation if you knew just a little more about the schema. you could also think of running the whole string in a transaction to test for regression.

 

For example this is tedious for short INSERTs:

INSERT INTO test_bean 

(string_prop, long_prop, timets)

VALUES (

'HELLO' -- {stringProp}

, 3000 -- {longProp}

, now() -- {timeTS}

)

But for really long inserts with many columns its actually convenient.

 

But on the java side, wouldn't the principle of immutable POJO force you to write things like

myNewTestBeanRecord = new TestBean( "Hello", 3000, "World", "Happy", "New", "Year" (insert a dozen more values here all-the-same-type-that-are-easily-inverted) )?

Best

[Lukas Eder]

> But on the java side, wouldn't the principle of immutable POJO force you to
> write things like
> myNewTestBeanRecord = new TestBean( "Hello", 3000, "World", "Happy", "New",
> "Year" (insert a dozen more values here
> all-the-same-type-that-are-easily-inverted) )?

jOOQ 2.6 supports the java.beans.ConstructorProperties annotation, to
be sure that record values are mapped to the correct constructor
arguments:
http://www.jooq.org/doc/2.6/manual/sql-execution/fetching/pojos/#N11C85

Adam's JIRM goes a little farther and uses Jackson annotations, such as these:

@JsonCreator
public TestBean(
@JsonProperty("stringProp") String stringProp,
@JsonProperty("longProp") long longProp,
@JsonProperty("timeTS") Calendar timeTS ) {

(taken from the samples here: https://github.com/agentgt/jirm)

For jOOQ, a dependency on Jackson is currently not an option, though.

[Adam Gent]

Yes Java does not make it easy to work with Immutable objects.

Most people combat this issue with "builders" that make it easier to make the objects.

Protobuf infact does this automatically for you: https://developers.google.com/protocol-buffers/docs/javatutorial

There are also several annotation processing libraries: http://code.google.com/p/make-builder/ and http://code.google.com/p/genftw/

At some point I might look into making protobuf generators that have some sort JPA extension. Its unclear how you add meta data to protobuf.

Or an annotation processing extension (JSR-269) to JIRM (which is the more likely route).

[Adam Gent]

Just to clarify... Jackson is also a dependency not just because of the annotations but it powers the hierarchical mapping.

That is with Jackson you can turn maps of maps into hierarchy of objects. There are other libraries that do this but Jackson does this very well.

[Stéphane Cl]

On Sunday, November 4, 2012 5:58:50 PM UTC+1, Lukas Eder wrote:

Adam's JIRM goes a little farther and uses Jackson annotations, such as these:

    @JsonCreator
    public TestBean(
            @JsonProperty("stringProp") String stringProp,
            @JsonProperty("longProp") long longProp,
            @JsonProperty("timeTS") Calendar timeTS ) {

Yes but the java object that will be used as parameter to that SQL-with-placeholder insert query he mentionned, I guess you will have to populate it with some values before feeding it to the query.

And if it's immutable, you'll have no other ways than using constructors to specify all the values which tends to become error-prone as parameter lists grow. There's often no more than 3 or 4 different value types in a table, so it may be easy to switch order. 

Perhaps this immutability problem could be solved by the mean of interfaces rather than final fields,

You insert : you create the object, you can use accessor, you select : you receive an interface that has no mutators...  just an idea as that's probably not the goal...