Skip to main content

[jpa-spec issues] [JIRA] Commented: (JPA_SPEC-36) Support for more automatic values besides @GeneratedId

  • From: "mkarg (JIRA)" < >
  • To:
  • Subject: [jpa-spec issues] [JIRA] Commented: (JPA_SPEC-36) Support for more automatic values besides @GeneratedId
  • Date: Fri, 9 May 2014 18:00:49 +0000 (UTC)
  • Auto-submitted: auto-generated


    [ 
https://java.net/jira/browse/JPA_SPEC-36?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=375229#action_375229
 ] 

mkarg commented on JPA_SPEC-36:
-------------------------------

Nope, not mixing anything. JPA is an integral part of EJB. Certainly there 
are still entities in EJB: JPA entities. I didn't say "entity beans". "JPA 
3.1" means "JPA as of EJB 3.1".

> Support for more automatic values besides @GeneratedId
> ------------------------------------------------------
>
>                 Key: JPA_SPEC-36
>                 URL: https://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 
> applications.
> * @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 
> databases.
> * @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 
> "javax.persistence.jdbc.user".

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://java.net/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


[jpa-spec issues] [JIRA] Commented: (JPA_SPEC-36) Support for more automatic values besides @GeneratedId

kithouna (JIRA) 05/09/2014

<Possible follow-up(s)>

[jpa-spec issues] [JIRA] Commented: (JPA_SPEC-36) Support for more automatic values besides @GeneratedId

mkarg (JIRA) 05/09/2014
 
 
Close
loading
Please Confirm
Close