Hi Lewis,

As you've probably guessed, QueryChangeListener is used to fire notifications that a query/table has changed its structure or schema, but not when data rows are inserted/updated/deleted.

I think that Ben's thought about trigger scripts is a good direction to investigate. If you haven't already found the docs, they're here:

https://www.labkey.org/wiki/home/Documentation/page.view?name=serverSideValidation

Each script is associated by naming convention with a specific schema and query. You'd likely want a more generic registration mechanism so that you don't need to add one per dataset, and to be able to register in Java code. You can see where they get invoked in:

server\api\src\org\labkey\api\etl\TriggerDataBuilderHelper.java : BeforeIterator.next(), AfterIterator.next()

and

server\api\src\org\labkey\api\query\AbstractQueryUpdateService.java : deleteRows(), updateRows(), etc

Perhaps adding a new Java interface for listeners to implement, having a registration mechanism on QueryService, and hooking it into TableInfo.fireRowTrigger() and TableInfo.fireBatchTrigger() might be a good approach to pursue?

However, this assumes that you have code that registers itself and runs within the LabKey Server process itself. A custom implementation could, of course, fire off messages to an external process.

Alternatively, you could also use the Java API to monitor for new audit events that indicate that dataset rows have changed (see the auditLog schema's DatasetAuditEvent query for how these look). This could be done external to the server, but would require polling for changes instead of being actively notified.

Thanks,
Josh