You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jdo-dev@db.apache.org by Craig L Russell <Cr...@Sun.COM> on 2006/06/09 03:11:02 UTC
Behavior of projection queries (long)
Javadogs,
For the JDO maintenance release, we have to decide what the behavior
is for projection queries of various kinds of fields. [There are no
TCK tests for this behavior.] Consider this class:
class Company {
int id;
String symbol;
Date incorporated;
BigDecimal revenues;
Set<Department> departments;
Locale hqLocale;
Integer empCount;
Address hqAddress;
}
and these JDOQL queries:
Collection<DTOCompany> dtos = execute this query: "SELECT new
DTOCompany(symbol, incorporated, revenues, departments, hqLocale,
empCount, hqAddress) FROM Company ORDER BY id"
Collection<Company> cos = execute this query: "SELECT FROM Company
ORDER BY id"
1. Now, iterate the collections of dtos and cos. For each
corresponding result dto and co in the collection of results:
For each of symbol, incorporated, revenues, departments, hqLocale,
empCount, and hqAddress:
Does dto.symbol == co.symbol?
Does dto.symbol.equals(co.symbol)?
2. Now, suppose I change the mutable second class fields of the
instances I get from cos (the persistent instances).
tx.begin();
cos.incorporated.setTime(new Date().getMillis());
tx.commit();
tx.begin();
cos.departments.add(new Department());
tx.commit();
tx.begin();
cos.hqAddress.setState("CA");
tx.commit();
Have I modified the company instance in the database in any of these
cases?
3.Now, suppose I change the mutable second class fields of the
instances I get from dtos (the holders for the field values of the
instances).
tx.begin();
dtos.incorporated.setTime(new Date().getMillis());
tx.commit();
tx.begin();
dtos.departments.add(new Department());
tx.commit();
tx.begin();
dtos.hqAddress.setState("CA");
tx.commit();
Have I modified the company instance in the database in any of the
cases?
Here's a proposal to clarify the specification.
If mutable second class fields are selected by a projection query,
the instances returned by the query are the instances of the owning
first class instance. Changes made to the results are reflected in
the database at transaction commit. There is no requirement that
immutable fields returned by a projection query are identical to
corresponding fields in cached instances.
The implication is that a projection query that selects mutable
second class fields has the effect of instantiating the owning first
class instance and associating the mutable second class fields in the
query result with the owning first class instance. So selecting first
name, last name, age, and ssn returns only values not associated with
persistent instances. But selecting incorporated, departments, or
hqAddress will instantiate the first class instances and its default
fetch group.
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!
Re: Behavior of projection queries (long)
Posted by Craig L Russell <Cr...@Sun.COM>.
Hi,
I think we're all coming pretty close to agreement summarized by David:
>> In my opinion, the rule should always be: projected SCOs are never
>> owned,
>> projected FCOs are always managed. Modifying unowned SCOs never
>> has an
>> effect on the database. Modifying FCOs no matter how you get them
>> always has
>> an effect if the tx commits (except for the well know corner case of
>> modifying just the unowned side of a bidirectional relationship).
>> That's
>> what most developers would expect.
Except for the fact that changes to either side of a bidirectional
relationship actually do affect the database at commit time.
<spec>
15.3
...
Regardless of which side
changes the relationship, flush (whether done as part of commit or
explicitly by the user)
will modify the datastore to reflect the change and will update the
memory model for consistency.
</spec>
I'll go with the consensus here:
The rule should always be: projected SCOs are never owned,
projected FCOs are always managed. Modifying unowned SCOs never has an
effect on the database. Modifying FCOs no matter how you get them
always has
an effect if the tx commits.
Craig
On Jun 15, 2006, at 7:39 AM, Michael Bouschen wrote:
> Hi,
>
> after reading David's reply and the discussion during the JDO TCK
> conference call I think returning an owned SCO from a JDOQL
> projection query is not a good idea. The whole point in supporting
> projection queries is to be able to return field values without the
> need to instantiate the entire instance. This means SCO's returned
> from a query are never owned. This implies that mutable SCO
> instances need to be cloned if the owning instance is already
> loaded. For immutable SCO instances it is a decision of the JDO
> implementation whether to clone or not.
>
> Regards Michael
>> More inline
>>
>> Quoting David Ezzio <de...@bea.com>:
>>
>>
>>> Hi Craig,
>>>
>>> Comments inline.
>>>
>>> David
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: Craig L Russell [mailto:Craig.Russell@Sun.COM]
>>> Sent: Thu 6/8/2006 9:11 PM
>>> To: JDO Expert Group; Apache JDO project
>>> Subject: Behavior of projection queries (long)
>>>
>>> Javadogs,
>>>
>>> For the JDO maintenance release, we have to decide what the behavior
>>> is for projection queries of various kinds of fields. [There are no
>>> TCK tests for this behavior.] Consider this class:
>>>
>>> class Company {
>>> int id;
>>> String symbol;
>>> Date incorporated;
>>> BigDecimal revenues;
>>> Set<Department> departments;
>>> Locale hqLocale;
>>> Integer empCount;
>>> Address hqAddress;
>>> }
>>>
>>> and these JDOQL queries:
>>>
>>> Collection<DTOCompany> dtos = execute this query: "SELECT new
>>> DTOCompany(symbol, incorporated, revenues, departments, hqLocale,
>>> empCount, hqAddress) FROM Company ORDER BY id"
>>>
>>>
>>
>> This query will raise JDOUserException, Collection fields cannot
>> be projected.
>>
>>
>>> Collection<Company> cos = execute this query: "SELECT FROM Company
>>> ORDER BY id"
>>>
>>> 1. Now, iterate the collections of dtos and cos. For each
>>> corresponding result dto and co in the collection of results:
>>>
>>> For each of symbol, incorporated, revenues, departments, hqLocale,
>>> empCount, and hqAddress:
>>>
>>> Does dto.symbol == co.symbol?
>>>
>>> ***
>>> NO
>>>
>>>
>>
>> I'm not sure if would be a good idea to take the SCO instance from
>> the FCO or
>> not. Maybe in pratical terms for users NOT, but logically YES.
>>
>>
>>> Does dto.symbol.equals(co.symbol)?
>>>
>>> ***
>>> YES
>>>
>>> 2. Now, suppose I change the mutable second class fields of the
>>> instances I get from cos (the persistent instances).
>>>
>>> tx.begin();
>>> cos.incorporated.setTime(new Date().getMillis());
>>> tx.commit();
>>>
>>> tx.begin();
>>> cos.departments.add(new Department());
>>> tx.commit();
>>>
>>> tx.begin();
>>> cos.hqAddress.setState("CA");
>>> tx.commit();
>>>
>>> Have I modified the company instance in the database in any of these
>>> cases?
>>>
>>> ***
>>> YES
>>>
>>>
>>> 3.Now, suppose I change the mutable second class fields of the
>>> instances I get from dtos (the holders for the field values of the
>>> instances).
>>>
>>> tx.begin();
>>> dtos.incorporated.setTime(new Date().getMillis());
>>> tx.commit();
>>>
>>> tx.begin();
>>> dtos.departments.add(new Department());
>>> tx.commit();
>>>
>>> tx.begin();
>>> dtos.hqAddress.setState("CA");
>>> tx.commit();
>>>
>>> ***
>>> Maybe, but only if Address is a first class object.
>>>
>>> Have I modified the company instance in the database in any of the
>>> cases?
>>>
>>> Here's a proposal to clarify the specification.
>>>
>>> If mutable second class fields are selected by a projection query,
>>> the instances returned by the query are the instances of the owning
>>> first class instance. Changes made to the results are reflected in
>>> the database at transaction commit. There is no requirement that
>>> immutable fields returned by a projection query are identical to
>>> corresponding fields in cached instances.
>>>
>>> The implication is that a projection query that selects mutable
>>> second class fields has the effect of instantiating the owning first
>>> class instance and associating the mutable second class fields in
>>> the
>>> query result with the owning first class instance. So selecting
>>> first
>>> name, last name, age, and ssn returns only values not associated
>>> with
>>> persistent instances. But selecting incorporated, departments, or
>>> hqAddress will instantiate the first class instances and its default
>>> fetch group.
>>>
>>> ***
>>> I'm sure you have a very good reason in mind. Perhaps I missed it.
>>>
>>>
>>
>> I see Craig's point, however as you point below it may be trick
>> for users.
>>
>> Collections and maps fields cannot be projected, so we have only
>> non set fields
>> left and allowing them to affect the database would not be much
>> benefit.
>>
>>
>>> One the one side, I fail to see the virtues of this proposal. On
>>> the other
>>> side, the whole point of projections is to avoid instantiating
>>> first class
>>> objects (although the collections produced may be collections of
>>> first class
>>> objects). Likewise, projected values should never be owned by
>>> first class
>>> objects.
>>>
>>> The proposal adds yet another corner case that will confuse,
>>> snare, and
>>> flabbergast application developers.
>>>
>>> In my opinion, the rule should always be: projected SCOs are
>>> never owned,
>>> projected FCOs are always managed. Modifying unowned SCOs never
>>> has an
>>> effect on the database. Modifying FCOs no matter how you get
>>> them always has
>>> an effect if the tx commits (except for the well know corner case of
>>> modifying just the unowned side of a bidirectional
>>> relationship). That's
>>> what most developers would expect.
>>> ***
>>>
>>> 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!
>>>
>>>
>>> ____________________________________________________________________
>>> ___
>>> Notice: This email message, together with any attachments, may
>>> contain
>>> information of BEA Systems, Inc., its subsidiaries and
>>> affiliated
>>> entities, that may be confidential, proprietary, copyrighted
>>> and/or
>>> legally privileged, and is intended solely for the use of the
>>> individual
>>> or entity named in this message. If you are not the intended
>>> recipient,
>>> and have received this message in error, please immediately
>>> return this
>>> by email and then delete it.
>>>
>>>
>>
>>
>>
>
>
> --
> Michael Bouschen Tech@Spree Engineering GmbH
> mailto:mbo.tech@spree.de http://www.tech.spree.de/
> Tel.:++49/30/235 520-33 Buelowstr. 66
> Fax.:++49/30/2175 2012 D-10783 Berlin
>
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!
Re: Behavior of projection queries (long)
Posted by Michael Bouschen <mb...@spree.de>.
Hi,
after reading David's reply and the discussion during the JDO TCK
conference call I think returning an owned SCO from a JDOQL projection
query is not a good idea. The whole point in supporting projection
queries is to be able to return field values without the need to
instantiate the entire instance. This means SCO's returned from a query
are never owned. This implies that mutable SCO instances need to be
cloned if the owning instance is already loaded. For immutable SCO
instances it is a decision of the JDO implementation whether to clone or
not.
Regards Michael
> More inline
>
> Quoting David Ezzio <de...@bea.com>:
>
>
>> Hi Craig,
>>
>> Comments inline.
>>
>> David
>>
>>
>>
>> -----Original Message-----
>> From: Craig L Russell [mailto:Craig.Russell@Sun.COM]
>> Sent: Thu 6/8/2006 9:11 PM
>> To: JDO Expert Group; Apache JDO project
>> Subject: Behavior of projection queries (long)
>>
>> Javadogs,
>>
>> For the JDO maintenance release, we have to decide what the behavior
>> is for projection queries of various kinds of fields. [There are no
>> TCK tests for this behavior.] Consider this class:
>>
>> class Company {
>> int id;
>> String symbol;
>> Date incorporated;
>> BigDecimal revenues;
>> Set<Department> departments;
>> Locale hqLocale;
>> Integer empCount;
>> Address hqAddress;
>> }
>>
>> and these JDOQL queries:
>>
>> Collection<DTOCompany> dtos = execute this query: "SELECT new
>> DTOCompany(symbol, incorporated, revenues, departments, hqLocale,
>> empCount, hqAddress) FROM Company ORDER BY id"
>>
>>
>
> This query will raise JDOUserException, Collection fields cannot be projected.
>
>
>> Collection<Company> cos = execute this query: "SELECT FROM Company
>> ORDER BY id"
>>
>> 1. Now, iterate the collections of dtos and cos. For each
>> corresponding result dto and co in the collection of results:
>>
>> For each of symbol, incorporated, revenues, departments, hqLocale,
>> empCount, and hqAddress:
>>
>> Does dto.symbol == co.symbol?
>>
>> ***
>> NO
>>
>>
>
> I'm not sure if would be a good idea to take the SCO instance from the FCO or
> not. Maybe in pratical terms for users NOT, but logically YES.
>
>
>> Does dto.symbol.equals(co.symbol)?
>>
>> ***
>> YES
>>
>> 2. Now, suppose I change the mutable second class fields of the
>> instances I get from cos (the persistent instances).
>>
>> tx.begin();
>> cos.incorporated.setTime(new Date().getMillis());
>> tx.commit();
>>
>> tx.begin();
>> cos.departments.add(new Department());
>> tx.commit();
>>
>> tx.begin();
>> cos.hqAddress.setState("CA");
>> tx.commit();
>>
>> Have I modified the company instance in the database in any of these
>> cases?
>>
>> ***
>> YES
>>
>>
>> 3.Now, suppose I change the mutable second class fields of the
>> instances I get from dtos (the holders for the field values of the
>> instances).
>>
>> tx.begin();
>> dtos.incorporated.setTime(new Date().getMillis());
>> tx.commit();
>>
>> tx.begin();
>> dtos.departments.add(new Department());
>> tx.commit();
>>
>> tx.begin();
>> dtos.hqAddress.setState("CA");
>> tx.commit();
>>
>> ***
>> Maybe, but only if Address is a first class object.
>>
>> Have I modified the company instance in the database in any of the
>> cases?
>>
>> Here's a proposal to clarify the specification.
>>
>> If mutable second class fields are selected by a projection query,
>> the instances returned by the query are the instances of the owning
>> first class instance. Changes made to the results are reflected in
>> the database at transaction commit. There is no requirement that
>> immutable fields returned by a projection query are identical to
>> corresponding fields in cached instances.
>>
>> The implication is that a projection query that selects mutable
>> second class fields has the effect of instantiating the owning first
>> class instance and associating the mutable second class fields in the
>> query result with the owning first class instance. So selecting first
>> name, last name, age, and ssn returns only values not associated with
>> persistent instances. But selecting incorporated, departments, or
>> hqAddress will instantiate the first class instances and its default
>> fetch group.
>>
>> ***
>> I'm sure you have a very good reason in mind. Perhaps I missed it.
>>
>>
>
> I see Craig's point, however as you point below it may be trick for users.
>
> Collections and maps fields cannot be projected, so we have only non set fields
> left and allowing them to affect the database would not be much benefit.
>
>
>> One the one side, I fail to see the virtues of this proposal. On the other
>> side, the whole point of projections is to avoid instantiating first class
>> objects (although the collections produced may be collections of first class
>> objects). Likewise, projected values should never be owned by first class
>> objects.
>>
>> The proposal adds yet another corner case that will confuse, snare, and
>> flabbergast application developers.
>>
>> In my opinion, the rule should always be: projected SCOs are never owned,
>> projected FCOs are always managed. Modifying unowned SCOs never has an
>> effect on the database. Modifying FCOs no matter how you get them always has
>> an effect if the tx commits (except for the well know corner case of
>> modifying just the unowned side of a bidirectional relationship). That's
>> what most developers would expect.
>> ***
>>
>> 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!
>>
>>
>> _______________________________________________________________________
>> Notice: This email message, together with any attachments, may contain
>> information of BEA Systems, Inc., its subsidiaries and affiliated
>> entities, that may be confidential, proprietary, copyrighted and/or
>> legally privileged, and is intended solely for the use of the individual
>> or entity named in this message. If you are not the intended recipient,
>> and have received this message in error, please immediately return this
>> by email and then delete it.
>>
>>
>
>
>
--
Michael Bouschen Tech@Spree Engineering GmbH
mailto:mbo.tech@spree.de http://www.tech.spree.de/
Tel.:++49/30/235 520-33 Buelowstr. 66
Fax.:++49/30/2175 2012 D-10783 Berlin
RE: Behavior of projection queries (long)
Posted by Erik Bengtson <er...@jpox.org>.
More inline
Quoting David Ezzio <de...@bea.com>:
> Hi Craig,
>
> Comments inline.
>
> David
>
>
>
> -----Original Message-----
> From: Craig L Russell [mailto:Craig.Russell@Sun.COM]
> Sent: Thu 6/8/2006 9:11 PM
> To: JDO Expert Group; Apache JDO project
> Subject: Behavior of projection queries (long)
>
> Javadogs,
>
> For the JDO maintenance release, we have to decide what the behavior
> is for projection queries of various kinds of fields. [There are no
> TCK tests for this behavior.] Consider this class:
>
> class Company {
> int id;
> String symbol;
> Date incorporated;
> BigDecimal revenues;
> Set<Department> departments;
> Locale hqLocale;
> Integer empCount;
> Address hqAddress;
> }
>
> and these JDOQL queries:
>
> Collection<DTOCompany> dtos = execute this query: "SELECT new
> DTOCompany(symbol, incorporated, revenues, departments, hqLocale,
> empCount, hqAddress) FROM Company ORDER BY id"
>
This query will raise JDOUserException, Collection fields cannot be projected.
> Collection<Company> cos = execute this query: "SELECT FROM Company
> ORDER BY id"
>
> 1. Now, iterate the collections of dtos and cos. For each
> corresponding result dto and co in the collection of results:
>
> For each of symbol, incorporated, revenues, departments, hqLocale,
> empCount, and hqAddress:
>
> Does dto.symbol == co.symbol?
>
> ***
> NO
>
I'm not sure if would be a good idea to take the SCO instance from the FCO or
not. Maybe in pratical terms for users NOT, but logically YES.
> Does dto.symbol.equals(co.symbol)?
>
> ***
> YES
>
> 2. Now, suppose I change the mutable second class fields of the
> instances I get from cos (the persistent instances).
>
> tx.begin();
> cos.incorporated.setTime(new Date().getMillis());
> tx.commit();
>
> tx.begin();
> cos.departments.add(new Department());
> tx.commit();
>
> tx.begin();
> cos.hqAddress.setState("CA");
> tx.commit();
>
> Have I modified the company instance in the database in any of these
> cases?
>
> ***
> YES
>
>
> 3.Now, suppose I change the mutable second class fields of the
> instances I get from dtos (the holders for the field values of the
> instances).
>
> tx.begin();
> dtos.incorporated.setTime(new Date().getMillis());
> tx.commit();
>
> tx.begin();
> dtos.departments.add(new Department());
> tx.commit();
>
> tx.begin();
> dtos.hqAddress.setState("CA");
> tx.commit();
>
> ***
> Maybe, but only if Address is a first class object.
>
> Have I modified the company instance in the database in any of the
> cases?
>
> Here's a proposal to clarify the specification.
>
> If mutable second class fields are selected by a projection query,
> the instances returned by the query are the instances of the owning
> first class instance. Changes made to the results are reflected in
> the database at transaction commit. There is no requirement that
> immutable fields returned by a projection query are identical to
> corresponding fields in cached instances.
>
> The implication is that a projection query that selects mutable
> second class fields has the effect of instantiating the owning first
> class instance and associating the mutable second class fields in the
> query result with the owning first class instance. So selecting first
> name, last name, age, and ssn returns only values not associated with
> persistent instances. But selecting incorporated, departments, or
> hqAddress will instantiate the first class instances and its default
> fetch group.
>
> ***
> I'm sure you have a very good reason in mind. Perhaps I missed it.
>
I see Craig's point, however as you point below it may be trick for users.
Collections and maps fields cannot be projected, so we have only non set fields
left and allowing them to affect the database would not be much benefit.
> One the one side, I fail to see the virtues of this proposal. On the other
> side, the whole point of projections is to avoid instantiating first class
> objects (although the collections produced may be collections of first class
> objects). Likewise, projected values should never be owned by first class
> objects.
>
> The proposal adds yet another corner case that will confuse, snare, and
> flabbergast application developers.
>
> In my opinion, the rule should always be: projected SCOs are never owned,
> projected FCOs are always managed. Modifying unowned SCOs never has an
> effect on the database. Modifying FCOs no matter how you get them always has
> an effect if the tx commits (except for the well know corner case of
> modifying just the unowned side of a bidirectional relationship). That's
> what most developers would expect.
> ***
>
> 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!
>
>
> _______________________________________________________________________
> Notice: This email message, together with any attachments, may contain
> information of BEA Systems, Inc., its subsidiaries and affiliated
> entities, that may be confidential, proprietary, copyrighted and/or
> legally privileged, and is intended solely for the use of the individual
> or entity named in this message. If you are not the intended recipient,
> and have received this message in error, please immediately return this
> by email and then delete it.
>
RE: Behavior of projection queries (long)
Posted by David Ezzio <de...@bea.com>.
Hi Craig,
Comments inline.
David
-----Original Message-----
From: Craig L Russell [mailto:Craig.Russell@Sun.COM]
Sent: Thu 6/8/2006 9:11 PM
To: JDO Expert Group; Apache JDO project
Subject: Behavior of projection queries (long)
Javadogs,
For the JDO maintenance release, we have to decide what the behavior
is for projection queries of various kinds of fields. [There are no
TCK tests for this behavior.] Consider this class:
class Company {
int id;
String symbol;
Date incorporated;
BigDecimal revenues;
Set<Department> departments;
Locale hqLocale;
Integer empCount;
Address hqAddress;
}
and these JDOQL queries:
Collection<DTOCompany> dtos = execute this query: "SELECT new
DTOCompany(symbol, incorporated, revenues, departments, hqLocale,
empCount, hqAddress) FROM Company ORDER BY id"
Collection<Company> cos = execute this query: "SELECT FROM Company
ORDER BY id"
1. Now, iterate the collections of dtos and cos. For each
corresponding result dto and co in the collection of results:
For each of symbol, incorporated, revenues, departments, hqLocale,
empCount, and hqAddress:
Does dto.symbol == co.symbol?
***
NO
Does dto.symbol.equals(co.symbol)?
***
YES
2. Now, suppose I change the mutable second class fields of the
instances I get from cos (the persistent instances).
tx.begin();
cos.incorporated.setTime(new Date().getMillis());
tx.commit();
tx.begin();
cos.departments.add(new Department());
tx.commit();
tx.begin();
cos.hqAddress.setState("CA");
tx.commit();
Have I modified the company instance in the database in any of these
cases?
***
YES
3.Now, suppose I change the mutable second class fields of the
instances I get from dtos (the holders for the field values of the
instances).
tx.begin();
dtos.incorporated.setTime(new Date().getMillis());
tx.commit();
tx.begin();
dtos.departments.add(new Department());
tx.commit();
tx.begin();
dtos.hqAddress.setState("CA");
tx.commit();
***
Maybe, but only if Address is a first class object.
Have I modified the company instance in the database in any of the
cases?
Here's a proposal to clarify the specification.
If mutable second class fields are selected by a projection query,
the instances returned by the query are the instances of the owning
first class instance. Changes made to the results are reflected in
the database at transaction commit. There is no requirement that
immutable fields returned by a projection query are identical to
corresponding fields in cached instances.
The implication is that a projection query that selects mutable
second class fields has the effect of instantiating the owning first
class instance and associating the mutable second class fields in the
query result with the owning first class instance. So selecting first
name, last name, age, and ssn returns only values not associated with
persistent instances. But selecting incorporated, departments, or
hqAddress will instantiate the first class instances and its default
fetch group.
***
I'm sure you have a very good reason in mind. Perhaps I missed it.
One the one side, I fail to see the virtues of this proposal. On the other side, the whole point of projections is to avoid instantiating first class objects (although the collections produced may be collections of first class objects). Likewise, projected values should never be owned by first class objects.
The proposal adds yet another corner case that will confuse, snare, and flabbergast application developers.
In my opinion, the rule should always be: projected SCOs are never owned, projected FCOs are always managed. Modifying unowned SCOs never has an effect on the database. Modifying FCOs no matter how you get them always has an effect if the tx commits (except for the well know corner case of modifying just the unowned side of a bidirectional relationship). That's what most developers would expect.
***
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!
_______________________________________________________________________
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and affiliated
entities, that may be confidential, proprietary, copyrighted and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.