checkRemoveGroup - removeGroup should be before getGroups

• Key: JDO-402
• Type: Bug
• Status: Resolved
• Resolution: Fixed
• Priority: Major
• Assignee: Craig Russell
• Reporter: Ilan Kirsh
• Component/s: tck2
• Affects Version/s: JDO 2 final
• Fix Version/s: JDO 2 maintenance release 1

Description

In org.apache.jdo.tck.api.persistencemanager.fetchplan.FetchPlanInterface, lines 281-282,

it probably has to be:
        fp.removeGroup("default");
        Collection groups = fp.getGroups();

Instead of:
        Collection groups = fp.getGroups();
        fp.removeGroup("default");

Comments

[Craig Russell]

Need to resolve these issues for maintenance release 1.

This changes the test as suggested by Ilan.

I don't understand how the original test could have worked. Still looking.

[Ilan Kirsh]

Thanks for the fix. I assume that the old code should work fine if the implementation returns from getGroup a shared set that is still used by the FetchPlan.

[Craig Russell]

The spec is silent on whether the return can be a "live" object. I had assumed that it was not shared but copied (all other "value" objects in the specification are defined as copied). I'll raise this with the expert group.

[Andy Jefferson]

The spec isnt totally silent (12.7.5 comment line in the code for getGroups). Erik asked the question on the mailing list on 15th Feb 2006, and a knowledgeable person replied that it is immutable, see
http://mail-archives.apache.org/mod_mbox/db-jdo-dev/200602.mbox/[e-mail]%3e

[Craig Russell]

Hi Andy,

The spec does say the returned Set is immutable but that doesn't necessarily mean that the underlying Set is immutable as well. That is, there is room for the Set to change based on the underlying groups. But I think it makes sense to return an immutable Set that will never change, even if the underlying groups changes.

[Andy Jefferson]

Understood. The original test does fail with the change to backing store copy (in JPOX CVS). Just need someone to apply the patch to tck20 ;-)

[Erik Bengtson]

It was implicitly understood that the returned Set is immutable because the underlying Set is a reference. If the underlying set is a copy, it does not make sense to be immutable.

Anyway, I dont have any problem if it's changed to copy. In this case, making the returned set mutable is better for usability.

[Craig Russell]

svn commit -m "JDO-402 Change order of removeGroups and getGroups" src/java/org/apache/jdo/tck/api/persistencemanager/fetchplan/FetchPlanInterface.java
Sending src/java/org/apache/jdo/tck/api/persistencemanager/fetchplan/FetchPlanInterface.java
Transmitting file data .
Committed revision 429180.