db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Bouschen <mbo.t...@spree.de>
Subject Re: Behavior of projection queries (long)
Date Thu, 15 Jun 2006 14:39:53 GMT
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 <dezzio@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			


Mime
View raw message