Re: Behavior of projection queries (long)

[Craig L Russell]

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

what most developers would expect.

modifying just the unowned side of a bidirectional relationship). That's

<spec>
15.3
...
Regardless of which side

</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

an effect if the tx commits.

Craig

On Jun 15, 2006, at 7:39 AM, Michael Bouschen wrote:

Except for the fact that changes to either side of a bidirectional relationship actually do affect the database at commit time. 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. effect on the database. Modifying FCOs no matter how you get them always has

Hi,



Regards Michael

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.

More inline

Quoting David Ezzio <[EMAIL PROTECTED]>:

Hi Craig,

Comments inline.

David



-----Original Message-----
From: Craig L Russell [mailto:[EMAIL PROTECTED]
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

not. Maybe in pratical terms for users NOT, but logically YES.

I'm not sure if would be a good idea to take the SCO instance from the FCO or

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

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.

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

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.


flabbergast application developers.


an effect if the tx commits (except for the well know corner case of

what most developers would expect.
***

  Craig

Craig Russell

The proposal adds yet another corner case that will confuse, snare, and 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 modifying just the unowned side of a bidirectional relationship). That's Architect, Sun Java Enterprise System http://java.sun.com/ products/jdo

408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!



by email and then delete it.

____________________________________________________________________ ___ 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

--
Michael Bouschen                [EMAIL PROTECTED] Engineering GmbH
mailto:[EMAIL PROTECTED]        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:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!

smime.p7s
Description: S/MIME cryptographic signature