Hi! Thanks for fixing this. Much appreciated. We're really looking forward to 3.5 :o) Today I found another oddity regarding updating views:
I do: create.select().from(UNTBEH).where(UNTBEH.TERMIN_UBTID.eq( BigDecimal.valueOf( 10L ) )).forUpdate().noWait().fetchOne(); This is supposed to lock the record in the database .... and it does ..... if it is called on a table. When I run the same statement, but use a 1:1 view on top of the same table, then no lock is performed. The forUpdate() method is still available and the statement succeeds even if the record is actually already locked in the database. I need to explicitly specify forUpdate().of(UNTBEH) so that a lock is set it seems. For an Oracle developer this is tough, since in Oracle the OF ... (as in FOR UPDATE OF ....) isn't required in that situation. If he/she forgets to append the of() call then the code silently decides to not lock after all without the developer actually realizing it. Of course it would be nice of the lock would actually work. Alternatively, I would prefer an exception to be thrown (if the developer issues forUpdate() on something that cannot be locked by the framework if no of() call is there) over a silent omission of the lock. Or is there a technical reason for the current behavior? Regards, Sascha Am Montag, 6. Oktober 2014 10:46:51 UTC+2 schrieb Lukas Eder: > > > > 2014-09-25 8:25 GMT+02:00 Lukas Eder <[email protected] <javascript:>>: > >> Hello, >> >> I'm responding to the second question of another thread here, in a new >> thread, to simplify tracking of the different questions. >> >> 2014-09-24 19:49 GMT+02:00 Sascha Herrmann <[email protected] >> <javascript:>>: >> >>> Secondly, we run into a NullPointerException. >>> >>> We're inserting into an Oracle database using a simple view. The view >>> sits 1:1 on top of a single table. We're calling DSLContext#newRecord() to >>> get a new record created for that view. Nothing fancy. >>> The record provides an insert() method. But when we call the insert() >>> method, we get: >>> >>> ..... >>> Caused by: >>> *java.lang.NullPointerException* at >>> org.jooq.impl.TableRecordImpl.getReturning(*TableRecordImpl.java:315*) >>> at org.jooq.impl.TableRecordImpl.storeInsert0( >>> *TableRecordImpl.java:171*) >>> at org.jooq.impl.TableRecordImpl$1.operate( >>> *TableRecordImpl.java:141*) >>> at org.jooq.impl.RecordDelegate.operate(*RecordDelegate.java:123* >>> ) >>> at org.jooq.impl.TableRecordImpl.storeInsert( >>> *TableRecordImpl.java:137*) >>> at org.jooq.impl.TableRecordImpl.insert( >>> *TableRecordImpl.java:130*) >>> at org.jooq.impl.TableRecordImpl.insert( >>> *TableRecordImpl.java:125*) >>> at .... .UserCreationProvider$1.run( >>> *UserCreationProvider.java:180*) >>> at org.jooq.impl.DefaultDSLContext$1.run( >>> *DefaultDSLContext.java:352*) >>> at org.jooq.impl.DefaultDSLContext$1.run( >>> *DefaultDSLContext.java:349*) >>> at org.jooq.impl.DefaultDSLContext.transactionResult( >>> *DefaultDSLContext.java:330*) >>> at org.jooq.impl.DefaultDSLContext.transaction( >>> *DefaultDSLContext.java:349*) >>> at .... .UserCreationProvider.createUser( >>> *UserCreationProvider.java:210*) >>> >>> >>> It seems that the record tries to add the key fields to a returning >>> clause. Since a view doesn't have primary keys, getPrimaryKey() most like >>> returns null and the insert() statements runs into the NPE. >>> >>> For now we added a hack (put the jOOQ internal flag that switches off >>> returning clauses into the jOOQ configuration), but that's probably not the >>> way it should be. >>> >> >> I suspect you're talking about the >> "org.jooq.configuration.omit-returning-clause" flag? I was just going to >> suggest that hack as a workaround :-) >> A better short-term workaround might be to use the syntheticPrimaryKeys >> code generation flag: >> >> <!-- A regular expression matching all columns that participate in >> "synthetic" primary keys, >> which should be placed on generated UpdatableRecords, to be used with >> >> - UpdatableRecord.store() >> - UpdatableRecord.update() >> - UpdatableRecord.delete() >> - UpdatableRecord.refresh() >> >> Synthetic primary keys will override existing primary keys. --> >> <syntheticPrimaryKeys>SCHEMA\.TABLE\.COLUMN(1|2)</syntheticPrimaryKeys> >> >> >> This will generate the missing primary key information also on the view, >> if you know that this view is updatable in the sense of Oracle "updatable >> views". >> >> Note that we're still looking for a way to automatically detect view >> updatability in the code generator. Unfortunately, so far, with no avail: >> http://stackoverflow.com/q/5500738/521799 >> >> I understand that a record on a view doesn't have an update method >>> (because of a lack of primary keys), and that we need to call >>> create.executeUpdate(). But for inserting, no such method exists as far as >>> I can tell and inserting on a view should be possible using a record, IMHO. >>> >> >> You're absolutely right. This is a bug and should be fixed. I have >> registered an issue to track this: >> https://github.com/jOOQ/jOOQ/issues/3650 >> > > This issue is now fixed on master for jOOQ 3.5.0: > https://github.com/jOOQ/jOOQ/issues/3650 > -- 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.
