|
Home > Archive > Apache JDO Project > July 2006 > [VOTE]: Should FetchPlan.getGroups return a copy or a reference?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
[VOTE]: Should FetchPlan.getGroups return a copy or a reference?
|
|
| Craig L Russell 2006-07-30, 7:11 pm |
| | |
| Ilan Kirsh 2006-07-30, 7:11 pm |
| Personally I prefer:
[] Require the jdo implementation to return a read-only copy of the underlying Set of groups as it exists at the time of the call.
But anything else is also acceptable, except:
[ ] Require the jdo implementation to return a read-only reference to the underlying implementation that will continue to track modifications made to the Set of groups.
which makes things complicated for implementations (like ObjectDB) that do not use a standard Java Collection to maintain the set of fetch groups internally.
Ilan
----- Original Message -----
From: Craig L Russell
To: JDO Expert Group ; Apache JDO project
Sent: Sunday, July 30, 2006 9:58 PM
Subject: [VOTE]: Should FetchPlan.getGroups return a copy or a reference?
Javadogs,
During testing of FetchPlan, Ilan Kirsh discovered that the jdo specification doesn't specify whether getGroups returns a read-only copy of the set of fetch groups or can return a read-only reference to the actual set of fetch groups. [The specification does require returning a read-only Set.]
The TCK as it was written requires a read-only reference, not a copy.
This can result in non-portable behavior, if the application code expects a "live" reference instead of a copy. The TCK currently has the following code, which depends on the jdo implementation returning a "live" reference:
public void checkRemoveGroup() {
Set expectedGroups = new HashSet();
FetchPlan fp = getPM().getFetchPlan();
Collection groups = fp.getGroups(); // this assumes that groups is updated by the following line
fp.removeGroup("default");
if (!setEquals(expectedGroups, groups)) {
failCompare(
"checkRemoveGroup(): wrong getGroups() " +
"after removeGroup.",
expectedGroups, groups);
}
cleanupPM();
}
Please advise:
[ ] Leave it alone.
[ ] Update the specification to note that getGroups returns a Set that might change if the underlying Set of groups changes (via addGroup, addGroups, removeGroup, removeGroups, clearGroups).
[ ] Require the jdo implementation to return a read-only reference to the underlying implementation that will continue to track modifications made to the Set of groups.
[ ] Require the jdo implementation to return a read-only copy of the underlying Set of groups as it exists at the time of the call.
Thanks,
Craig
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
| |
| Erik Bengtson 2006-07-30, 7:11 pm |
| [X] Require the jdo implementation to return a read-only reference to
the underlying implementation that will continue to track
modifications made to the Set of groups.
+ requires the Set to be the same reference after clearGroups()
Quoting Craig L Russell <Craig.Russell@Sun.COM>:
> Javadogs,
>
> During testing of FetchPlan, Ilan Kirsh discovered that the jdo
> specification doesn't specify whether getGroups returns a read-only
> copy of the set of fetch groups or can return a read-only reference
> to the actual set of fetch groups. [The specification does require
> returning a read-only Set.]
>
> The TCK as it was written requires a read-only reference, not a copy.
>
> This can result in non-portable behavior, if the application code
> expects a "live" reference instead of a copy. The TCK currently has
> the following code, which depends on the jdo implementation returning
> a "live" reference:
>
> public void checkRemoveGroup() {
> Set expectedGroups = new HashSet();
> FetchPlan fp = getPM().getFetchPlan();
> Collection groups = fp.getGroups(); // this assumes that
> groups is updated by the following line
> fp.removeGroup("default");
> if (!setEquals(expectedGroups, groups)) {
> failCompare(
> "checkRemoveGroup(): wrong getGroups() " +
> "after removeGroup.",
> expectedGroups, groups);
> }
> cleanupPM();
> }
>
> Please advise:
>
> [ ] Leave it alone.
>
> [ ] Update the specification to note that getGroups returns a Set
> that might change if the underlying Set of groups changes (via
> addGroup, addGroups, removeGroup, removeGroups, clearGroups).
>
> [ ] Require the jdo implementation to return a read-only reference to
> the underlying implementation that will continue to track
> modifications made to the Set of groups.
>
> [ ] Require the jdo implementation to return a read-only copy of the
> underlying Set of groups as it exists at the time of the call.
>
> Thanks,
>
> Craig
>
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
>
| |
| Bin Sun 2006-07-31, 1:11 am |
| [X] Require the jdo implementation to return a
read-only copy of the underlying Set of groups as it
exists at the time of the call.
FetchPlan.getGroups() should be a state investigation,
keeping the state read-only with no more change from
either inside or outside.
--- Craig L Russell <Craig.Russell@Sun.COM> wrote:
> Javadogs,
>
> During testing of FetchPlan, Ilan Kirsh discovered
> that the jdo
> specification doesn't specify whether getGroups
> returns a read-only
> copy of the set of fetch groups or can return a
> read-only reference
> to the actual set of fetch groups. [The
> specification does require
> returning a read-only Set.]
>
> The TCK as it was written requires a read-only
> reference, not a copy.
>
> This can result in non-portable behavior, if the
> application code
> expects a "live" reference instead of a copy. The
> TCK currently has
> the following code, which depends on the jdo
> implementation returning
> a "live" reference:
>
> public void checkRemoveGroup() {
> Set expectedGroups = new HashSet();
> FetchPlan fp = getPM().getFetchPlan();
> Collection groups = fp.getGroups(); // this
> assumes that
> groups is updated by the following line
> fp.removeGroup("default");
> if (!setEquals(expectedGroups, groups)) {
> failCompare(
> "checkRemoveGroup(): wrong
> getGroups() " +
> "after removeGroup.",
> expectedGroups, groups);
> }
> cleanupPM();
> }
>
> Please advise:
>
> [ ] Leave it alone.
>
> [ ] Update the specification to note that getGroups
> returns a Set
> that might change if the underlying Set of groups
> changes (via
> addGroup, addGroups, removeGroup, removeGroups,
> clearGroups).
>
> [ ] Require the jdo implementation to return a
> read-only reference to
> the underlying implementation that will continue to
> track
> modifications made to the Set of groups.
>
> [ ] Require the jdo implementation to return a
> read-only copy of the
> underlying Set of groups as it exists at the time of
> the call.
>
> Thanks,
>
> Craig
>
> Craig Russell
> Architect, Sun Java Enterprise System
> http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
>
________________________________________
__________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
| |
| Craig L Russell 2006-07-31, 7:11 pm |
| |
|
|
|
|