Hi Vasily > The use case is just proper handling of query parameters. It's a shame JDBC > does not support them natively like say ADO.NET.
That's true. Named parameters really are missing. > I just thought it might have been possible to do it in a limited manner: the > parameters are already ordered as necessary across all query parts and it's > a matter of maintaining a map by name internally to reference already > created parameters. Now only their values are held in query instance (in a > List). Unfortunately, there is no such list, currently. I designed jOOQ to model an AST: http://en.wikipedia.org/wiki/Abstract_syntax_tree That means that all objects composing a query are called QueryParts and they render their relevant SQL and bind their relevant variables. Here is an example of how this works: http://www.jooq.org/manual/JOOQ/QueryPart/ The Query.getBindValues() method actually uses a dummy PreparedStatement called BindValueCollector that traverses the AST and makes every QueryPart bind their values to a result list: https://github.com/lukaseder/jOOQ/blob/master/jOOQ/src/main/java/org/jooq/impl/BindValueCollector.java Allowing for returning bind values back to the QueryParts would require quite an (internal) API change. I fear that's not so easy to do, that's why I proposed some workarounds... I do agree, though, that it would be nice to be able to modify the bind values of an existing query from outside, and I'm open to implementation suggestions. I'll file this as a feature request for future improvements: https://sourceforge.net/apps/trac/jooq/ticket/914 By the way, another idea would be to create actual named parameters: // ---------------------------------------------- // Create a re-usable select Select<?> select = create.selectFrom(TABLE) .where(A.equal(param("a"))) .and(B.equal(param("b"))); // Do the actual binding in separate steps select.bind("a", 1).bind("b", 2).fetch(); // ---------------------------------------------- What do you think about this? I recently had this idea, because when executing SQL with Spring Templates, one often wants to use named parameters as well. That would make for another advantage of using jOOQ... Cheers Lukas
