AbstractAuditable should have an equivalent annotation similar to @Audited of Hibernate Envers [DATAJPA-116]

[spring-projects-issues]

Mark Serrano opened DATAJPA-116 and commented

When adding auditing capabilities my domain class is forced to extend from org.springframework.data.jpa.domain.AbstractAuditable

@Entity
public class Patient extends AbstractAuditable<User, Long> {
...
}

However, with Hibernate Envers, I just need to add @Audited

@Audited
@Entity
public class Patient {
...
}

Wouldn't it be nicer if we have an equivalent annotation for AbstractAuditable? Maybe like:

@Auditable(User.class, Long.class)
@Entity
public class Patient {
...
}

Thanks

---

Affects: 1.1 M1

Issue Links:

• DATACMNS-137 Separate the Auditable into two separate responsibilities: AuditableDate, AuditableBy

5 votes, 6 watchers

[spring-projects-issues]

Mark Serrano commented

I understand I'm "not really" forced to extend from AbstractAuditable but I can create my own class but then again, it's like creating from scratch when AbstractAuditable is already viable. And besides this custom class that I will be making isn't annotation too

[spring-projects-issues]

Oliver Drotbohm commented

I've started to sketch out a spec for a feature like this in a local ticket already so I'll just add it to the discussion here:

To use the auditing feature of Spring Data JPA entities have to implement the Auditable interface. It would be cool if we could introduce less obtrusive annotations to trigger the very same behaviour. Beyond the reduced dependency it also nicely allows being very selective about what properties shall be set for different classes. Using annotations we could also allow using references to the ID type of the entity being referenced instead of the entity itself.

I propose the following annotations to be introduced:

• @CreatedBy
• @CreatedDate
• @LastModifiedBy
• @LastModifiedDate

class MyEntity {

  @CreatedBy
  private User createdBy;
  @LastModifiedBy
  private Long lastModifiedBy;
  @CreatedDate
  private DateTime createdDate;
  @LastModifiedDate
  private DateTime lastModifiedDate;
  
  // …
}

For the dates we should support java.util.Date and org.joda.time.DateTime out of the box and could look into supporting java.sql.Date as well. We should also look into options of moving parts of that infrastructure into Spring Data Commons as the general entity meta model lookup and manipulation could be used to implement auditing for other stores as well.

[spring-projects-issues]

Eugen Paraschiv commented

Separating these responsibilities would be a very good thing, as the audit needs do not usually fit these exact four concerns.
Thanks.

[spring-projects-issues]

Nicholas Padilla commented

This does make sense to implement. It will also make it easier to upgrade existing code to use the Audit framework. I'll look at this a bit more myself next week

[spring-projects-issues]

Ranie Jade Ramiso commented

I am experimenting on this, my implementation is based on what Oliver proposed. Have not test it yet though, will do so in the weekend. The current implementation checks fields annotated with the proposed Annotations, and insert the appropriate values via reflection. My implementation revolves around the AuditingEntityListener

[spring-projects-issues]

Oliver Drotbohm commented

Good to hear, Ranie Jade Ramiso! It would be perfect if you could already try to split up the implementation into stuff that could make it into Spring Data Commons (annotations, generic support infrastructure) and the Spring Data JPA specific adapter (i.e. the AuditingEntityListener implementation).

If you don't have the time to get into that, feel free to submit a pull request of whatever kind. I'll sort that stuff out then myself

[spring-projects-issues]

Ranie Jade Ramiso commented

Hi Oliver I did separate the implementation. Take a look at it for the data commons part at my fork. I can submit a pull request if you like