Bottleneck - docu chapter 7

[agorski]

Hi,
here is my opinion/proposition according bottleneck REVINFO table:
1. Maybe it is reasonable to add an annotation to disable revisions (entries in REVINFO table). It is also possible to add parameter to @Audited annotation.
2. An idea with group(s) could give additionally a possibility to denote the REVINFO table name. Again it could be done by new annotation or new property of @Audited. It makes sense to give a user possibility easily to say what is the name of REVINFO table.

Example:

@Entity
@Audited(revisions=true, group="REV1")
public class Class1 {.....}

@Entity
@Audited(revisions=true, group="REV2")
public class Class2 {.....}

@Entity
@Audited(revisions=true)
public class Class3 {.....}

@Entity
@Audited(revisions=false)
public class Class4 {.....}

Here:
Class1 revision is enabled (by default) and table name is REV1
Class2 revision is enabled (by default) and table name is REV2
Class3 revision is enabled and table name is REVINFO (default name, table ALWAYS created)
Class4 revision is disabled and changes are out of scope of revision.

Regards,
Albert

[adamw]

Hello,

I think auditing without revisions doesn't make much sense ... unless you only want to store the modification date, and no other metadata. You also loose the capability to resolve the relations correctly.

Right now you can specify the name of the revision table in the configuration. But as you write, the general idea with revision groups is this.

Adam

[agorski]

Hi,

generally auditing without revisions is not an intention but :) in every system there are exceptions where you want to exclude something.
I think create a software which is flexible and match different requirements is a target. You cannot judge the client requirements ... which are sometimes hard to understand.

As we discussed about revision groups I think there could be a group "unrevised" so without revision table and information - example could be a table with pictures stored as blob.

Albert

[adamw]

I agree with you, and I'm not completely against implementing this feautre :) Especially is somebody would contribute the code, I could just include it :)

If you want to audit only "simple" properties (that is: not relations, collections), then it's possible of course. You would only store the modification date, instead of the revision number. Such entities would require special treatment then reading them with the audit reader, but that wouldn't be very hard to adapt.

Adam