Hi Vlad, Thanks for the feedback. Yes, the jOOQ DSL is not 100% immutable. This is documented in the following section: http://www.jooq.org/doc/latest/manual/sql-building/sql-statements/dsl-and-non-dsl
Glad it worked out for you, now. Cheers, Lukas 2015-05-29 12:48 GMT+02:00 <[email protected]>: > Hi Lukas, > > Please ignore. It was our problem: an instance created by db.select(...) > was reused having .from(...) invoked several times on it, while it actually > creates sort of a builder object with further methods, i.e. .from(...), > updating the same instance rather than returning a new one. > > Thanks, > Vlad > > > On Wednesday, May 27, 2015 at 1:09:59 PM UTC+1, Lukas Eder wrote: >> >> Hello Vlad, >> >> Thank you very much for your report. That looks indeed a bit frightening. >> But also surprising - we're not aware of any such regression that might >> have arised from upgrading to jOOQ 3.6. >> >> The FROM clause is generated in SelectQueryImpl as simply as this: >> >> if (hasFrom) { >> context.formatSeparator() >> .keyword("from") >> .sql(' ') >> .visit(getFrom()); >> >> The only place that adds to the org.jooq.impl.TableList (returned by >> getFrom()) in order to produce a comma-separated table list is >> SelectQueryImpl.addFrom(), which is in turn called via SelectImpl.from(), >> i.e. the method where you pass the USERS table. >> >> - Do you get that problem elsewhere as well, i.e. in other queries? >> - Do you do any SQL transformation via ExecuteListeners or VisitListeners? >> - Have you tried debugging through the SQL generation to see why / where >> exactly the additional table reference is generated? >> >> Best Regards, >> Lukas >> >> 2015-05-27 12:59 GMT+02:00 <[email protected]>: >> >>> Hi, >>> >>> After upgrading from 3.5.0 to 3.6.1 one of our queries stopped working. >>> >>> db.select( >>> USERS.ID.as("id"), >>> USERS.FIRST_NAME.as("first_name"), >>> USERS.LAST_NAME.as("last_name"), >>> USERS.PHONE.as("phone"), >>> USERS.EMAIL.as("email")) >>> .from(USERS) >>> .where(coalesce(USERS.FIRST_NAME, "").concat(" >>> ").concat(coalesce(USERS.LAST_NAME, "")).likeIgnoreCase("%" + searchTerm + >>> "%") >>> .or(USERS.PHONE.contains(searchTerm)) >>> .or(USERS.EMAIL.contains(searchTerm))) >>> >>> started generating this: >>> >>> select >>> USERS.ID as ID, >>> USERS.FIRST_NAME as FIRST_NAME, >>> USERS.LAST_NAME as LAST_NAME, >>> USERS.PHONE as PHONE, >>> USERS.EMAIL as EMAIL >>> *from USERS, USERS* >>> where ((((coalesce(USERS.FIRST_NAME, ?) || ?) || coalesce(USERS.LAST_NAM >>> E, ?)) ilike ? or USERS.PHONE like ('%' || ? || '%') escape '!' or >>> USERS.EMAIL like ('%' || ? || '%') escape '!') and >>> (((coalesce(USERS.FIRST_NAME, ?) || ?) || coalesce(USERS.LAST_NAME, ?)) >>> ilike ? or USERS.PHONE like ('%' || ? || '%') escape '!' or USERS.EMAIL >>> like ('%' || ? || '%') escape '!')) limit ? >>> >>> Dialect: POSTGRESQL. Using generated static table definitions. >>> >>> Can you please point out if we are doing smth wrong or it's a bug? >>> >>> >>> Thanks. >>> >>> Vlad >>> >>> -- >>> 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. > -- 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.
