> Hum, no, it'd be task of the code on the receiving end to identify those entities affected by given table data changes. The task of determining these entities needs to be done with either approach.

Yes I agree but I meant to point out that - as a user - I'd expect the frameworks to help define to which events it will listen to (i.e. which tables and columns we care about) and then from the received events being able to push the updates to the object model.
I guess from there we'll need to trigger more database reads, as the event will contain only the changes but building a Lucene Document doesn't work via updates of fields, so we need to rebuild it all including fields which haven't been changed: these need to be fetched; for consistency reasons then I guess you'd need to re-fetch the whole entity graph. Ideally the listener could be pushing updates to an in-memory data grid which is caching the whole DB

The alternative is that the RDBMs listener pushes not just the delta but the full graph of needed fields; but I'm afraid that gets complex too quickly and would require our libraries.