Hello, > Or just a general property change listener like in a JavaBean. That way I > can bind it to a user interface field and if the record is updated from > somewhere other than the bound UI field, then the UI can be updated.
Hmm, maybe this is indeed an option. After all, jOOQ-generated records and JavaBeans have some things in common (getters, setters, etc.) Maybe, there is a way to implement this at the client side, using jooq-codegen's generated interfaces (which are implemented by the records)? Although those interfaces wouldn't be able to capture all possible events. > I think this would need to be implemented in the Record. But the trigger > idea sounds interesting. I'm all for hooks into Jooq. The more the merrier > :). I thought you'd think so :-) If there are triggers, records could have hooks that notify all applicable triggers > What kind of events do you think could be hooked into using the trigger? The general idea was to have jOOQ triggers work much like SQL triggers. I.e. provide actions before/after/instead of insert/update/delete, etc. I.e. a more high-level ExecuteListener. But I haven't finished my thinking about this feature yet. On a second thought, it doesn't seem to be an applicable way to implement listeners on records... I'd just like to avoid adding too many different ways of hooking callbacks into jOOQ. Having too many options would be: - hard to document - hard to understand - hard to maintain Cheers Lukas
