Spring Roo
  1. Spring Roo
  2. ROO-1467

Updating an entity with DataNucleaus provider leads to inserting a new entity

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Deferred
    • Affects Version/s: 1.1.0.M3
    • Fix Version/s: 1.1.0.RELEASE
    • Component/s: PERSISTENCE
    • Labels:
      None

      Description

      1. Create an application using either of the following scripts (the only difference is DATANUCLEAUS vs. DATANUCLEAUS_2)

      // DATANUCLEAUS (1)
      project --topLevelPackage com.vmforce.dndemo
      persistence setup --provider DATANUCLEUS --database H2_IN_MEMORY
      entity --class ~.domain.Fan --identifierType java.lang.String
      field string --fieldName firstName
      field string --fieldName lastName
      field date --fieldName joinDate --type java.util.Date
      controller all --package ~.web

      // DATANUCLEUS_2
      project --topLevelPackage com.vmforce.dndemo
      persistence setup --provider DATANUCLEUS_2 --database H2_IN_MEMORY
      entity --class ~.domain.Fan --identifierType java.lang.String
      field string --fieldName firstName
      field string --fieldName lastName
      field date --fieldName joinDate --type java.util.Date
      controller all --package ~.web

      2. Run the resulting web app
      3. Create an entity
      4. Update that entity
      5. In List all Fans, you will see two entities: one with original values and another with updated.

      The same project works fine with HIBERNATE, ECLIPSELINK, or OPENJPA as providers. So this is probably DATANUCLEAUS bug (specifically, how it implements EntityManager.merge()). However, if possible, we may have to compensate for that in Roo.

        Issue Links

          Activity

          Hide
          Alan Stewart added a comment -

          This is a DataNucleus issue and will be deferred

          Show
          Alan Stewart added a comment - This is a DataNucleus issue and will be deferred
          Hide
          Andy Jefferson added a comment -

          Well it's actually a JPA spec issue. Nowhere does the JPA spec state that calling "merge()" on a transient object with PK fields set needs to go to the datastore and check if there exists a persistent object with that PK, and if so then attach this object. If you use DataNucleus v3.0 you can set persistent property "datanucleus.allowAttachOfTransient" as "true" and you can get that behaviour.

          Obviously since Oracle prevented the DataNucleus project having access to the JPA2 TCK then we can't see any implicit logic embedded in their tests, so have to base our handling on what is actually written in the spec.

          Show
          Andy Jefferson added a comment - Well it's actually a JPA spec issue. Nowhere does the JPA spec state that calling "merge()" on a transient object with PK fields set needs to go to the datastore and check if there exists a persistent object with that PK, and if so then attach this object. If you use DataNucleus v3.0 you can set persistent property "datanucleus.allowAttachOfTransient" as "true" and you can get that behaviour. Obviously since Oracle prevented the DataNucleus project having access to the JPA2 TCK then we can't see any implicit logic embedded in their tests, so have to base our handling on what is actually written in the spec.

            People

            • Assignee:
              Alan Stewart
              Reporter:
              Ramnivas Laddad
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: