jOOQ 3.17 will support client side computed columns, which will probably cover most of these use-cases: https://github.com/jOOQ/jOOQ/issues/9879
On Tuesday, May 30, 2017 at 11:26:25 AM UTC+2 Lukas Eder wrote: > For the record, after some additional consideration (and after this > feature has been requested 2-3 more times), I have now rejected issue #4706: > https://github.com/jOOQ/jOOQ/issues/4706 > > This is the reason: > > We shouldn't trigger RecordListener. The listener is only triggered on > actual UpdatableRecord.store()methods, and similar. In this case, the > record is "abused" as a Map, whose contents is simply transferred to some > other data structure. We don't know: > > > - If that insert statement is really executed > - If it works (in the DB) > - If it actually runs an insert (or perhaps an update, in the case > of INSERT .. ON DUPLICATE KEY UPDATE) > > It would be unwise to tie the RecordListener lifecycle to this API usage. > > > In particular when using INSERT .. ON DUPLICATE KEY UPDATE, then the > semantics of a RecordListener isn't really clear anymore. Sure, we could > shoe-horn this record state transfer somehow into listener events, but the > behaviour would be rather unexpected. > > Hope this helps, > Lukas > > Am Donnerstag, 5. November 2015 09:36:51 UTC+1 schrieb Lukas Eder: >> >> Thank you for your additional info. >> >> Just to be sure: Is using a trigger an option? This will be the best way >> to guarantee the integrity of these columns, regardless who is inserting / >> updating data, and how they're doing it. >> >> 2015-11-04 14:56 GMT+01:00 <[email protected]>: >> >>> Our use case is we have a DefaultRecordListener that overrides the >>> storeStart and insertStart methods to populate some created_at and >>> modified_at fields that all our tables have. >>> However, in one area we are performing a bulk insert using the >>> DSLContext.insertInto(Table, Fields) syntax.$ >>> >> >> I can see where the confusion originates, especially if you're passing >> the Record as a whole to the INSERT statement via >> InsertSetStep.set(Record). I'll investigate if that method qualifies for >> the RecordListener lifecycle. If it does, then we'd have a bug: >> https://github.com/jOOQ/jOOQ/issues/4706 >> >> In any case, the DSLContext.batchInsert(TableRecord...) method will >> generate the expected events. Perhaps, that's an option? It's really a >> batch insert, though, not a bulk insert. >> >> I tried registering a DefaultExecuteListener but all that gives me access >>> to is an ExecuteContext which doesn't seem to provide any methods to modify >>> the statement. To me that would seem the most logical place to provide some >>> hooks to modify the query before being executed. >>> >> >> The ExecuteListener is there to listen to JDBC statement lifecycle >> events. It doesn't have access to the SQL AST transformation and SQL string >> generation. If you want to get into the generation of the SQL statement, >> you'll need to implement a VisitListener: >> >> http://www.jooq.org/doc/latest/manual/sql-building/queryparts/custom-sql-transformation >> >> With a VisitListener, you can guarantee that all SQL INSERT / UPDATE >> statements generated by jOOQ will yield the correct additional clauses for >> CREATED_AT and MODIFIED_AT >> >> Hmm, I've just also found an old feature request for such audit fields: >> https://github.com/jOOQ/jOOQ/issues/1592 >> >> I think we should be able to implement that for jOOQ 3.8. The idea has >> popped up a couple of times. Also, it fits the idea of supporting SQL:2011 >> temporal validity in jOOQ 3.8 >> > -- 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]. To view this discussion on the web visit https://groups.google.com/d/msgid/jooq-user/7ca72f28-4cb4-4e54-819a-bb012455df8an%40googlegroups.com.
