Hi Ryan, > Perhaps that kind of functionality would be better in the "trigger" system > you were describing. eg. when a store() is issued, then the trigger could > fire and pass the record object, what fields were changed and if it was > being inserted or updated. It would save bloating the Record object.
The problem with the trigger is the fact that it is quite global. You will probably want to attach listeners to concrete record instaces... >> 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 > > I wonder of the memory and performance overhead that introduces? Yes, that's what I was wondering, too. >. I guess on > an initial query there are no listeners registered. And for a large query > you aren't going to register a listener on every record. In my use case I > would only want to register on an UpdatableRecord. Every record would hold one more reference (or null), which is OK. But I'm not such a big fan of adding one additional reference to every org.jooq.impl.Value object. Maybe there is a simpler implementation, that doesn't need one reference per value. > Getting a bit off topic... The more I have been using JOOQ, the more things > I keep wanting to add to it. It is a great project. It has really changed > the architecture of my system. It eliminates a lot of the data layer and > makes it a whole lot more agile. It would be great to be able to plug into > it in all kinds of places. So for me the more extension and plugin points > the better. I still want to implement an audit trail system, an extensive > validation system and a trigger system that all runs through JOOQ. Nothing that ExecuteListener could help you with, so far? I'm open to any more detailed elaboration of your ideas! > You made a suggestion earlier about using jooq-codegen. Maybe there could be > a way to "plug into" JOOQ by having the generated JOOQ record objects extend > from a custom class, or add hooks into a custom class. Then extra / custom > functionality could be inserted in there. I could then "intercept" all value > changes and use my own listener system that I coded in there. I guess that > is really similar to the proxy idea. Yes, in jOOQ 3.0, I hope a lot more will be possible out of the box, without rewriting parts of the code generator. Right now, you can only let your record classes implement custom interfaces, not extend custom classes. Cheers Lukas
