jpa-spec
  1. jpa-spec
  2. JPA_SPEC-55

Add variant of EntityManager#merge that modifies argument instead of returning new instance

    Details

    • Type: New Feature New Feature
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Labels:
      None

      Description

      The EntityManager's persist method modifies its argument (the entity to be persisted) with generated data such as the Id.

      The merge method can also be used to persist a new entity, but has the additional benefit that it can also update the entity or any of its relations in the DB. merge however does not modify its argument but returns a new instance in which the generated data such as the Id is set.

      For some uses cases its needed to have the original entity instance be modified such as the persist method does, but with the semantics of the merge method.

      For instance, in a JSF application an existing (persistent but detached) entity is passed into an action method to add a new entity into e.g. a @OneToMany relation. When the action method returns, rendering of the page begins, which still has a reference to the original entity. Depending on the backing bean and template structure of the page in question, it might not be trivial to have the action method replace this original reference that was passed into it, and the kind of update that persist does would be far more convenient.

      For this I would like to request adding a variant of EntityManager#merge that modifies its argument instead of returning a new instance.

      Alternatively a refresh method that accepts detached entities could also work for the above mentioned use case. Yet another alternative might be having an attach method that makes its argument attached, overwriting fields in that argument if an entity with the same identity happened to be present in the persistence context, but contrary to merge not updating any data in the database.

        Activity

        arjan tijms created issue -
        Hide
        ymajoros added a comment - - edited

        What if you end up having multiple instances referring to the same row in database? They would all end up in PC??

        If you do this in JSF, you really need to use the returned entity. If you can't do that, you have an architecture problem anyway.

        persist() returns the same entity because it's new, and this guaranteed to be unique. You can't do that with updates.

        Just curious: I don't really get your description of an attach() method that wouldn't update the database. Why would you want to have it managed by PC, but not updating the database? This is quite contrary to the basic ideas of JPA. Or am I missing something in your explanations?

        Show
        ymajoros added a comment - - edited What if you end up having multiple instances referring to the same row in database? They would all end up in PC?? If you do this in JSF, you really need to use the returned entity. If you can't do that, you have an architecture problem anyway. persist() returns the same entity because it's new, and this guaranteed to be unique. You can't do that with updates. Just curious: I don't really get your description of an attach() method that wouldn't update the database. Why would you want to have it managed by PC, but not updating the database? This is quite contrary to the basic ideas of JPA. Or am I missing something in your explanations?

          People

          • Assignee:
            Unassigned
            Reporter:
            arjan tijms
          • Votes:
            1 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated: