Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 316241

Summary: ObjectBuilder copyObject(Object original, CopyGroup copyGroup) copies all mappings even when CASCADE_PRIVATE_PARTS configured
Product: z_Archived Reporter: Doug Clarke <douglas.clarke>
Component: EclipselinkAssignee: Nobody - feel free to take it <nobody>
Status: CLOSED FIXED QA Contact:
Severity: normal    
Priority: P2 CC: andrei.ilitchev, eclipselink.foundation-inbox, tom.ware
Version: unspecified   
Target Milestone: ---   
Hardware: All   
OS: All   
Whiteboard:

Description Doug Clarke CLA 2010-06-09 01:46:35 EDT 
Starting at Line 1902 of ObjectBuilder the getCloneMappings() call returns all relationship mappings and they are not filered based on their private-owned configuration and the configuration of the CopyGroup. The result is that CASCADE_ALL_PARTS is used instead in all cases where CASCADE_TREE is not used.
Comment 1 Andrei Ilitchev CLA 2010-06-09 09:31:40 EDT 
The filtering performed in buildCopy method on the mapping: see CollectionMapping and ObjectReferenceMapping.
Comment 2 Doug Clarke CLA 2010-06-09 16:36:50 EDT 
I am running the following code:

        TypedQuery<Employee> query = em.createQuery("SELECT e FROM Employee e WHERE e.id IN (SELECT MIN(ee.id) FROM Employee ee)", Employee.class);

        Employee emp = query.getSingleResult();

        System.out.println(">>> Employee retrieved");

        // Copy only its names and phone Numbers
        CopyGroup group = new CopyGroup();
        group.cascadePrivateParts();
        group.setShouldResetPrimaryKey(true);
        group.setShouldResetVersion(true);
        
        Employee empCopy = (Employee) em.unwrap(JpaEntityManager.class).copy(emp, group);
   
        System.out.println(empCopy.getProjects().toString());


The result is that empCopy.projects has a collection where it should not since projects is not a private-owned relationship
Comment 3 Andrei Ilitchev CLA 2010-07-07 16:44:52 EDT 
Checked into trunk, 2.1.1 is pending.
see the patch in Bug 316242 - CopyGroup.CASCADE_TREE does not reset PK values on nested entities

In both SimpleSerializeFetchGroupTests and fieldaccess.SimpleSerializeFetchGroupTests added
copyWithPk and copyWithoutPk for bug 316242;
copyCascadePrivateParts for bug 316241.

Also fixed TransactionTests in examples/jpa.employee/eclipselink.example.jpa.employee.testing

Note that empCopy.projects still won't be empty - it will rather contain the same objects as the original emp - that's the way the original class ObjectCopyingPolicy always worked, and CopyGroup behaves the same way as ObjectCopyingPolicy (unless in CopyGroup.CASCADE_TREE mode). The only exception to this rule is that by default CopyGroup has shouldResetPrimaryKey set to true, whereas ObjectCopyingPolicy - to false.
Comment 4 Andrei Ilitchev CLA 2010-07-15 12:21:51 EDT 
Backported to 2.1.1.
Comment 5 Eclipse Webmaster CLA 2022-06-09 10:15:11 EDT 
The Eclipselink project has moved to Github: https://github.com/eclipse-ee4j/eclipselink
Comment 6 Eclipse Webmaster CLA 2022-06-09 10:27:55 EDT 
The Eclipselink project has moved to Github: https://github.com/eclipse-ee4j/eclipselink