Hello Ryan >> But it would probably be a clumsy solution, compared to actual >> listener support by jOOQ's core > > I thought about doing it a similar way. Very complicated for what would seem > like adding a few lines of code into the UpdatableRecord?
Yes it's a very complicated alternative. > Wouldn't it just > need to maintain a list of listeners and fire an event on setValue? Or is it > more complicated than I am imagining? OK, let's think this through 1. It is probably interesting to know WHY a value has been changed. So we should probably distinguish between 1.1. external setter calls 1.2. calls to fromXXX() methods, loading values into the record 1.3. calls to refresh(), or the new refresh(Field...) 1.4. calls to the new reset() or reset(Field) 1.5. calls to the new changed() methods, which change the internal flags 1.6. calls to store(), which change the internal flags (some special considerations may apply to batchStore) 1.7. calls to copy() (I'm not so sure what / whom to notify, though...) The above could be distinguished using a RecordChangeType enum 2. Some change events are interesting on a Record-level (1.2, 1.3, 1.4, 1.5, 1.6, 1.7). Some clients may be interested in listening to value-level change events, too (1.1, 1.3, 1.4, 1.5). While JavaBeans mainly knows PropertyChangeEvents (i.e. value-level change events), I think you may not always want to receive 20 "uncoordinated" events for a single refresh() 3. Since some of the event sources are not really "vetoable" on a value-level (1.3, 1.6), I don't think that a JavaBeans VetoableChangeSupport is generally applicable. PropertyVetoException being a checked exception, this might be irrelevant anyway. Hence, I'm guessing that events are fired *after* the change is made. 4. We would have a List<RecordChangeListener> within org.jooq.impl.AbstractRecord (all Record implementations), as well as a List<ValueChangeListener> within every org.jooq.impl.Value. A RecordChangeEvent would then contain a List<ValueChangeEvent>, every ValueChangeEvent would reference its parent RecordChangeEvent. Events would be fired as soon as there is at least one listener in the Record / in at least one Value 5. Listener types and Event types will have to be implemented in jOOQ. JavaBeans PropertyChangeEvent is probably too general, and too much focused on bean property changes in the context of AWT / Swing applications Any other points that I may have overlooked? Cheers Lukas
