[jpa-spec issues] [JIRA] Commented: (JPA_SPEC-36) Support for more automatic values besides @GeneratedId
- From: "mkarg (JIRA)" <
- Subject: [jpa-spec issues] [JIRA] Commented: (JPA_SPEC-36) Support for more automatic values besides @GeneratedId
- Date: Fri, 5 Apr 2013 16:46:53 +0000 (GMT+00:00)
- Auto-submitted: auto-generated
mkarg commented on JPA_SPEC-36:
Please mind that the alternative approach mentioned in that last chapter of
my original proposal is not copied to any of the four sub tasks. By closing
this master issue, this alternative solution might get lost in future
> Support for more automatic values besides @GeneratedId
> Key: JPA_SPEC-36
> URL: http://java.net/jira/browse/JPA_SPEC-36
> Project: jpa-spec
> Issue Type: New Feature
> Reporter: mkarg
> Assignee: ldemichiel
> Almost every no-nonsense business application (hence JPA application in the
> context of this issue) is in the need to support automatic values, i. e.
> values provided by JPA automatically without the support of a higher layer.
> Currently JPA only supports one type of automatic value: Generated IDs. For
> more convenient support of business applications it would be great if JPA
> could provide automatic values for more cases:
> * @CurrentUser to inject the current user to a data field (this is what
> databases do with the CURRENT USER constraint). As in the Java EE
> environment there is a difference between security principals, business
> layer people, and database accounts, there should be a mapping available.
> For example "@CurrentUser(type = PRINCIPAL_NAME) String createdBy" would
> default the content of "createdBy" to the name of the caller principal's
> name. This is the most common need for automatic values in business
> * @CurrentTimestamp to inject the current timestamp of a transaction into a
> data field. The annotation will guarantee that at the transaction start the
> timestamp is produced once, so all uses of the annotation within the same
> annotation will guarantee to inject the same timestamp value. This is
> another essential business need, as sometimes transactions run rather long,
> but all written data shall have synchronized timestamps.
> * @QuerySingleResult(ejbql = "JPAQL QUERY" | namedQuery = "name of query")
> to inject the .getSingleResult() output of either a given JPAQL query or of
> a named query into a field annotated with this annotation. This is often
> needed in business applications, for example if the written data is
> dependend of a aggregate other entities. This is what a trigger would do in
> * @PrePersist / @PreUpdate / @PostPersists / @PostUpdate annotations are
> used to define the event when the above annotations are to be injected.
> @PrePersist will be the most typical use case.
> As an alternative to this approach, all of the above could be solved easily
> with an entity listener, if it would be possible to inject an entity
> manager into it. While this would be the more flexible solution, it would
> also imply more complexity to the application's source code. Especially
> @CurrentUser is rather complex to implement, as it implies using
> ThreadLocal and / or TransactionSynchronizationRegistry to forward the
> current user from the EJB layer to the JPA layer. Also, this solution would
> be Java EE only, while @CurrentUser could be easily made Java SE, too, e.
> g. by providing a standard entity manager factory property
> "javax.persistence.currentuser" which defaults to
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see: http://www.atlassian.com/software/jira