On 11/02/2009, at 5:26 PM, Andrus Adamchik wrote:
The general idea was to expose the points where logging currently occurs via an event mechanism that we can continue to use for logging, but also for any other purpose (some yet unforeseen). The underlying motivation was indeed to build performance monitoring tools beyond simple logging. So the next step, after the right events are in place will be to provide a "JMX listener" to use Java JMX mechanism to expose basic query stats.
Would Cayenne keep aggregate statistics (min/av/max/count) tracked internally? That would make it easy for a user to monitor for slow selects without writing a listener at all.
It should be possible to do JDBC-level audit with this approach, however currently there's no link back to the objects being changed. On each update/insert/delete the event will expose a PreparedStatement SQL string and a map of parameters, with keys being column names. So not sure how useful this really is for audit (??) Although this whole thing will be tied to Cayenne thread transaction object, so theoretically you can store stuff in the transaction related to ObjectContext and tie that to the JDBC events.
It would seem that logging at that level for audit purposes is probably just as easy to achieve in the database itself with less work, so perhaps auditing is not a good use for the new QueryLogger events. Lifecycle events are a better place to put that.
Is there a symmetry between Lifecycle events which track the progress of an object entity, and these QueryLogger events which track what happens to the database (although not db entities?)?
Would QueryLogger listeners be something to be configured in the modeler?
Ari Maniatis --------------------------> ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
