jpa-spec
  1. jpa-spec
  2. JPA_SPEC-36

Support for more automatic values besides @GeneratedId

    Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Major Major
    • Resolution: Duplicate
    • Labels:
      None

      Description

      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".

        Activity

        Hide
        ldemichiel added a comment -

        I agree that these items differ in degree of complexity and environments in which they can be supported. I recommend that you split them out into separate issues so that we can better track for a subsequent JPA release.

        Show
        ldemichiel added a comment - I agree that these items differ in degree of complexity and environments in which they can be supported. I recommend that you split them out into separate issues so that we can better track for a subsequent JPA release.
        Hide
        mkarg added a comment -

        Done, please find the new sub tasks.

        Show
        mkarg added a comment - Done, please find the new sub tasks.
        Hide
        ldemichiel added a comment -

        This issue has been superseded by the 4 issues which have been separated out from it, so closing out.

        Show
        ldemichiel added a comment - This issue has been superseded by the 4 issues which have been separated out from it, so closing out.
        Hide
        mkarg added a comment -

        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 discussions.

        Show
        mkarg added a comment - 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 discussions.
        Hide
        mkarg added a comment -

        Linda, as I have not been in the JPA 3.1 EG and did not find something on the web about this topic, I would be glad if you could share some ideas how one can obtain the current user within an EJB 3.1 entity (as apparently my proposal did not make it into JPA 3.1).

        Show
        mkarg added a comment - Linda, as I have not been in the JPA 3.1 EG and did not find something on the web about this topic, I would be glad if you could share some ideas how one can obtain the current user within an EJB 3.1 entity (as apparently my proposal did not make it into JPA 3.1).
        Hide
        kithouna added a comment -

        Linda, as I have not been in the JPA 3.1 EG and did not find something on the web about this topic, I would be glad if you could share some ideas how one can obtain the current user within an EJB 3.1 entity (as apparently my proposal did not make it into JPA 3.1).

        I think you're mixing EJB and JPA here. There's no JPA 3.1 and there are no longer entities in EJB

        Show
        kithouna added a comment - Linda, as I have not been in the JPA 3.1 EG and did not find something on the web about this topic, I would be glad if you could share some ideas how one can obtain the current user within an EJB 3.1 entity (as apparently my proposal did not make it into JPA 3.1). I think you're mixing EJB and JPA here. There's no JPA 3.1 and there are no longer entities in EJB
        Hide
        mkarg added a comment -

        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".

        Show
        mkarg added a comment - 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".

          People

          • Assignee:
            ldemichiel
            Reporter:
            mkarg
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: