On 14/12/2012 8:46 PM, Lukas Eder wrote:
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'm not quite sure what you mean here? Do you mean having a setting in
the jooq.xml which says "generate ValueChangeEvents" or something along
those lines?
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
The idea sounds good. I would love this kind of functionality. Even to
implement say an audit trail. But as you have mentioned in the past it
is hard to capture these events, for instance for a merge statement it
is unknown which records would be updated / inserted and also in more
complicated updates. It would be fine for using the
UpdatableRecord.store() because it only works on a single record at at time.
I wonder if you could make an interface that plugs into different
databases capabilities to provide this functionality. For instance it
may need to create a database trigger which somehow communicates back to
JOOQ. I haven't used enough databases to know if this is even generally
possible. I guess at the least it would kill performance.
I don't think a global event would be suitable for what I am looking
for. For many other cases, yes, but in this case it would complicate
things (eg. I would have to remember to remove listeners from UI fields
when they are disposed, where usually the record would be disposed at
the same time as the UI, or beforehand)
Thanks, Ryan
