Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 316241 - ObjectBuilder copyObject(Object original, CopyGroup copyGroup) copies all mappings even when CASCADE_PRIVATE_PARTS configured
Summary: ObjectBuilder copyObject(Object original, CopyGroup copyGroup) copies all map...
Status: CLOSED FIXED
Alias: None
Product: z_Archived
Classification: Eclipse Foundation
Component: Eclipselink (show other bugs)
Version: unspecified   Edit
Hardware: All All
: P2 normal (vote)
Target Milestone: ---   Edit
Assignee: Nobody - feel free to take it CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-06-09 01:46 EDT by Doug Clarke CLA
Modified: 2022-06-09 10:27 EDT (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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