Issue Details (XML | Word | Printable)

Key: JDO-345
Type: Bug Bug
Status: Resolved Resolved
Resolution: Fixed
Priority: Major Major
Assignee: Michael Bouschen
Reporter: Ilan Kirsh
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
JDO

MethodsAndObjectConstructionNotSupported (A14.6.2-8) should allow getX()

Created: 22/Mar/06 11:10 AM   Updated: 05/Oct/06 03:17 PM
Return to search
Component/s: tck2
Affects Version/s: None
Fix Version/s: JDO 2 maintenance release 1, JDO 2 TCK challenge fixes

Time Tracking:
Not Specified

File Attachments:
  Size
Text File Licensed for inclusion in ASF works JDO-345.patch 2006-10-04 09:30 PM Michael Bouschen 2 kB

Resolution Date: 05/Oct/06 03:17 PM


 Description  « Hide
According to the spec:

 "Methods, including object construction, are not supported, except for Collection, String, and Map methods documented below. Implementations might choose to support non-mutating method calls as non-standard extensions."

However, MethodsAndObjectConstructionNotSupported expects an exception for method getX().

 All   Comments   Work Log   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Craig Russell added a comment - 22/Mar/06 11:18 AM
I agree that the test is invalid. There is nothing else of value in the test, so I propose to drop the test from the TCK.

Michael Bouschen added a comment - 23/Mar/06 06:23 AM
I agree we should drop the test from the TCK.

It might make sense to have a negative test case with a query calling a mutating method such as Collection.add. Calling a mutating method is not allowed in JDOQL.

Ilan Kirsh added a comment - 23/Mar/06 06:44 AM
I also think that this test should be dropped. A negative test might cause a new problem - how the implementation can check if a method is mutating in the general case? I think we already have enough byte code processing in the enhancer.

Craig Russell added a comment - 23/Mar/06 07:46 AM
I think a word about why we used the term "mutating method" is in order here.

The expert group did not want to allow the user and implementation to use query as a back door to a generalized UPDATE facility, so we said specifically that mutating methods were not allowed, even in vendor extensions. That said, there are only a small number of standard mutating methods that return a value, and hence even could be used in a filter.

So I think we are safe in dropping this test and we can debate the value of a new test later on if someone wants to raise the issue again.

Ilan Kirsh added a comment - 26/Mar/06 01:24 AM
On a second thought, maybe the test should be preserved as a negative test but refer to non existing methods? In this case an implementation that supports additional method as an extension should still throw an exception.

Ilan Kirsh added a comment - 09/Aug/06 08:23 AM
Can this be resolved for maintenance release 1? Simply by discarding the test or by switching to non existing methods?

Michael Bouschen added a comment - 04/Oct/06 09:30 PM
Attached you find a patch for review. I changed the test to call methods Collection.add and Collection.remove that are known to be mutating.

Ilan Kirsh added a comment - 04/Oct/06 10:40 PM
Thanks. A tiny comment - the import in line 24 (import org.apache.jdo.tck.JDO_Test) is not needed.

Craig Russell added a comment - 05/Oct/06 12:01 AM
The patch looks good.

Michael Bouschen added a comment - 05/Oct/06 03:17 PM
Cleaned up the imports and checked in the patch into the trunk and into branch 2.0.1 (see revision 453263).