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].
For more options, visit https://groups.google.com/d/optout.
