Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Auditing #83

Open
alvelig opened this issue Apr 16, 2017 · 4 comments
Open

Auditing #83

alvelig opened this issue Apr 16, 2017 · 4 comments

Comments

@alvelig
Copy link

alvelig commented Apr 16, 2017

What is the most conscious way to implement auditing in revenj? Ideally 'envers' like, but any idea would be welcome.

@zapov
Copy link
Member

zapov commented Apr 16, 2017

DSL has a concept of history. This will log all versions of an aggregate to a separate history table. Eg:

aggregate Table { 
  persistence { history; }
}

will create a separate history table. Though, API for reading this is not yet synchronized across different languages :( But it should be soon.

@alvelig
Copy link
Author

alvelig commented Apr 16, 2017

Great. Thanks a lot! May history track user who made the change? It would be great to have an example of that.

@zapov
Copy link
Member

zapov commented Apr 16, 2017

Yeah, I guess I should write small tutorial about that.

For now, the short answer is: you put them in you model.
Depending what means for you to track user who made the change that can be either

string modifiedBy;

or

User *modifiedBy;

A somewhat longer and confusing answer is:

Ideally when you want to track some specific information in audit log, you create a mixin for it, such as:

mixin Audited {
  User *modifiedBy;
  IP remoteAddress;
  ...
}

now you can apply that mixin to appropriate aggregates, either manually though has mixin Audited or in some other manner such as apply on all aggregates

If you have your own repositories you can set those properties before passing them along to Revenj repositories, either manually in specific repository, or in somewhat generic manner during deserialization, or something along those lines.

If you don't have your custom layer above Revenj and it's not easy to setup such generic application of audited properties, you can simulate (to a degree) such behavior via expressions on versioning concept:

string user { versioning 'it => Thread.CurrentPrincipal.Identity.Name'; }

@alvelig
Copy link
Author

alvelig commented Apr 16, 2017

The mixin idea also seems the best for me. Both ways are clear.

I'll try it myself, but will be looking forward to a tutorial, as this approach is new for me, although it seems much faster and clearer than everything that I've seen with type safety.

Thank you very much for your explanations. Feel free to close the issue, or you may have it open as a reminder to make a tutorial. If I manage to make a workable solution with auditing, I'll share it as a tutorial.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants