[
https://issues.apache.org/jira/browse/CAY-2030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrus Adamchik updated CAY-2030:
---------------------------------
Description:
Per http://www.mail-archive.com/dev@cayenne.apache.org/msg07968.html trying to
implement a proper transaction audit. After some thought, I think it should
work as follows:
0. ObjectChangeSet - an object that captures all changes for a single ObjectId
(including the change of ID itself)
1. ChangeCaptureFilter : A filter that captures all changes before and after
the commit (including generated PKs returned from DB) and stores them in a map
of <ObjectId,ObjectChangeSet>. Will notify the listeners after the commit.
2. A Module that registers the filter (once CAY-2028 is done, the module
should also take care of ordering the filter to go inside transaction).
3. Listener annotation:
{noformat}
@PostCommit
{noformat}
4. Listeners will be registered same way as other Cayenne listeners, and will
currently take the entire change set of the commit. Listener method format:
{noformat}
// grab changes as change objects
@PostCommit
void postCommit(Map<ObjectId, ObjectChangeSet>)
{noformat}
5. Context provider - a DI-supplied context provider that can give us client IP
address, identity name, etc.
For now there is no per-entity filtering, and the whole batch of audit data is
generated and passed to the listener. It can do its own filtering of course.
(since most people would want to run this filter within a TX, an effective
usage of this is dependent on CAY-2028; however the implementation is not)
was:
Per http://www.mail-archive.com/dev@cayenne.apache.org/msg07968.html trying to
implement a proper transaction audit. After some thought, I think it should
work as follows:
0. ObjectChangeSet - an object that captures all changes for a single ObjectId
(including the change of ID itself)
1. ChangeCaptureFilter : A filter that captures all changes before and after
the commit (including generated PKs returned from DB) and stores them in a map
of <ObjectId,ObjectChangeSet>. Will notify the listeners after the commit.
2. A Module that registers the filter (once CAY-2028 is done, the module
should also take care of ordering the filter to go inside transaction).
3. Listener annotation:
{noformat}
@PostCommit
{noformat}
4. Listeners will be registered same way as other Cayenne listeners,a dn will
currently take the entire change set of the commit. Listener method format:
{noformat}
// grab changes as change objects
@PostCommit
void postCommit(Map<ObjectId, ObjectChangeSet>)
// grab changes as JSON
@PostCommit
void postCommit(Map<ObjectId, String>)
{noformat}
In the second case (a map of Strings), Cayenne will perform JSON serialization
(serializer will be DI managed, so the format is configurable). Otherwise the
user will get a Map of ObjectChangeSet change objects.
5. Context provider - a DI-supplied context provider that can give us client IP
address, identity name, etc.
For now there is no per-entity filtering, and the whole batch of audit data is
generated and passed to the listener. It can do its own filtering of course.
(since most people would want to run this filter within a TX, an effective
usage of this is dependent on CAY-2028; however the implementation is not)
> @PostCommit and capturing a stream of commit changes
> ----------------------------------------------------
>
> Key: CAY-2030
> URL: https://issues.apache.org/jira/browse/CAY-2030
> Project: Cayenne
> Issue Type: Task
> Reporter: Andrus Adamchik
> Assignee: Andrus Adamchik
>
> Per http://www.mail-archive.com/dev@cayenne.apache.org/msg07968.html trying
> to implement a proper transaction audit. After some thought, I think it
> should work as follows:
> 0. ObjectChangeSet - an object that captures all changes for a single
> ObjectId (including the change of ID itself)
> 1. ChangeCaptureFilter : A filter that captures all changes before and after
> the commit (including generated PKs returned from DB) and stores them in a
> map of <ObjectId,ObjectChangeSet>. Will notify the listeners after the
> commit.
> 2. A Module that registers the filter (once CAY-2028 is done, the module
> should also take care of ordering the filter to go inside transaction).
> 3. Listener annotation:
> {noformat}
> @PostCommit
> {noformat}
> 4. Listeners will be registered same way as other Cayenne listeners, and will
> currently take the entire change set of the commit. Listener method format:
> {noformat}
> // grab changes as change objects
> @PostCommit
> void postCommit(Map<ObjectId, ObjectChangeSet>)
> {noformat}
> 5. Context provider - a DI-supplied context provider that can give us client
> IP address, identity name, etc.
> For now there is no per-entity filtering, and the whole batch of audit data
> is generated and passed to the listener. It can do its own filtering of
> course.
> (since most people would want to run this filter within a TX, an effective
> usage of this is dependent on CAY-2028; however the implementation is not)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
