cayenne-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrus Adamchik (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (CAY-2030) @PostCommit and capturing a stream of commit changes
Date Tue, 22 Sep 2015 19:54:04 GMT

     [ 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,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)

  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.

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,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)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message