Re: Is there a mechanism to retry a query on SQLException

2017-10-27 Thread Anthony Calce
ry function would be the most pragmatic approach here. You > could create an API like: > > // Retry this at most 3 times > retry(3, () -> { > db.deleteFrom(TABLE).where(TABLE.ID.eq(123)).execute(); > }); > > Hope this helps, > Lukas > > 2017-10-25 18:15 GMT+03:00

Is there a mechanism to retry a query on SQLException

2017-10-25 Thread Anthony Calce
Hello, My standard code for database calls looks like the following try (KrJooqWrapper wrapper = new KrJooqWrapper(DbType.MAIN)) { int rows = wrapper.getCreate() .deleteFrom(TABLE) .where(TABLE.ID.eq(123)) .execute(); return rows > 0; } catch (Exception e) { Log.exception(e); return false; } I

Re: Bug report

2017-05-09 Thread Anthony Calce
Also, if you could suggest a workaround I can use, it would be greatly appreciated On Tuesday, 9 May 2017 16:45:45 UTC-4, Anthony Calce wrote: > > Hello, > > We are using a custom time converter (from Timestamp to joda DateTime), > using MARIADB. The converter code is attached

Bug report

2017-05-09 Thread Anthony Calce
Hello, We are using a custom time converter (from Timestamp to joda DateTime), using MARIADB. The converter code is attached below. We have discovered the following bug: - When inserting records into the DB, a DateTime object is provided - If you apply breakpoints, you can see that the

Re: Bug found with forcedType possibly, only 1 is picked up

2017-02-01 Thread Anthony Calce
picked up (TINYINT to INTEGER) On Wednesday, 1 February 2017 03:20:34 UTC-5, Lukas Eder wrote: > > Thank you very much for reporting, Anthony. > > Would you mind showing also: > > - The DDL of your table > - The XML configuration of your code generator > > It's probab

Bug found with forcedType possibly, only 1 is picked up

2017-01-31 Thread Anthony Calce
Hello, I have found the following bug (MariaDB): - I am forcing type TINYINT to INTEGER - If I do a customType and forceType on a column (which is TINYINT), the generator doesn't pick up the converter correctly, and this column is typed as INTEGER (as per the type forcing rule).

Re: [REQUEST FOR FEEDBACK]: What small but incredibly useful utility are you missing the most in jOOQ?

2016-12-07 Thread Anthony Calce
wing error "Type class org.joda.time.DateTime is not supported in dialect DEFAULT". This solution isn't too appealing since I lose type information for the values. Any alternatives? On Wednesday, 7 December 2016 16:46:55 UTC-5, Anthony Calce wrote: > > Hey Lukas, >

Re: [REQUEST FOR FEEDBACK]: What small but incredibly useful utility are you missing the most in jOOQ?

2016-12-07 Thread Anthony Calce
Hey Lukas, Is it possible to use "NOW()" in an insert function. For example, the insert is to look like this INSERT INTO db.customer( account_number, cancel_date ) VALUES ( 1, NOW() ) The Jooq Query will look like wrapper.getCreate() .insertInto( CUSTOMER,

Generation field type issue

2016-06-06 Thread Anthony Calce
Hello, I have upgraded to 3.8.2 from 3.7.x and I have the following problem. In one database: - Table *customer* exists (contains column *notes,* which is of text type) - Table *customer_notes *exists After generating the classes, the *customer.notes* column is mapped as *CustomerNotesRecord*,

Re: Forced type conversion of Timestamp -- cannot use DSL date functions

2016-05-09 Thread Anthony Calce
ll a problem. I could create my own wrapper for each one which would work. I was wondering if there was a more elegant solution. On Monday, 9 May 2016 13:56:27 UTC-4, Anthony Calce wrote: > > Hello, > > I currently have an a forced type conversion of Timestamp to joda >

Forced type conversion of Timestamp -- cannot use DSL date functions

2016-05-09 Thread Anthony Calce
Hello, I currently have an a forced type conversion of Timestamp to joda DateTime. As a result, I am suffering from the following issues - cannot use any DSL function relating to dates (ie extract, date) since DateTime does not extend java.util.Date - Similar to above, I have no way

Re: Possible DefaultExecuteListener bug

2015-11-10 Thread Anthony Calce
ch bind variables aren't available via the ExecuteContext. You can > thus not access them in your logger. > > The NULL values that you're getting when rendering the query are the > values that you've passed to the query initially, but they have no meaning. > > Cheers, > Luka

Possible DefaultExecuteListener bug

2015-11-04 Thread Anthony Calce
Hello, First let me start off by saying that jOOQ is an amazing package. Excellent job on this. Now, to my question / possible bug. I have created my own custom wrapper for any jOOQ related operations. Below is an example code of the execution of a batch operation KrJooqWrapper wrapper =