I agree that the ValidTime may be misleading, and in fact I was also looking for a better name but failed to come up with one.
And what do you think about StartEndRevisionAuditStrategy, as in fact both revisions are used (not only the end-revision)?
Indeed: it can be difficult to find a good name for things such as strategies. Names should be distinctive, short and still describe its intented usage.
Of course, you're right that the start-revision is used by what's now called 'ValidAuditTimeStrategy', but this is also the case for the DefaultAuditStrategy. The use of an end-revision is what sets this strategy apart from the DefaultAuditStrategy. And not the fact that it uses a start-revision: that's what they have in common.
That's why I believe adding 'Start' to the Strategy doesn't add extra value.
I think that the difference between RevisionEndAuditStratigy or EndRevisionAudityStrategy is arbitrary. Personally I like EndRevisionAudityStrategy better.
The reason I originally proposed the name RevisionEndColumnAuditStrategy (had you spotted the typo ...) is that this strategy adds the revision-end column (not end-revision) to the audit tables.
But on second thoughts, I like EndRevisionAudityStrategy better.
And what do you think about ValidityAuditStrategy?
Thanks for creating the issue btw
That looks good to me.
This feature is a great improvement!
I would like to know if it's possible to switch from the original envers strategy to the new one and what are the necessary changes to achive that.
It would be great to have something like a strategy migration guide in the documentation...
Maybe the changes are trivial and this doesn't make sense... but I don't know.
What do you think?
I'm working on a bit more documentation of this feature, and the relevant trade-offs.
It should be possible to switch, but you only after you've added the new columns, and updated the values
I'm still thinking about a migration strategy. If you have a good idea then you're very welcome.
Maybe it should be a separate program that generates
* alter table statements
* update statements for all audit tables (and audit join tables)
The latter should be a repeatable process in the sense that all data is available.