Re: EmbeddedPCMapping cannot be cast to PersistableMapping

[Tilmann Zäschke <za...@gmx.de>]

The test mostly passes now. There are some issues, we should probably 
discuss them on Friday:

a)
SELECT FROM org.apache.jdo.tck.pc.query.OptionalSample WHERE 
!(optionalPC != null)
fails with
java.sql.SQLSyntaxErrorException: Syntax error: Encountered "NOT" at 
line 1, column 185

-> I think double negation is legal, would you agree?


b)
     query #1=  "optionalPC.id == " + DUMMY_ID
     query #2=  "optionalPC.get().id == " + DUMMY_ID
-> I think both queries should return the same result, but instead the 
second query returns the object with 'id=DUMMY_ID', not the one that 
refrerences the object with id=DUMMY_ID.

c) Optional.orElse is currently not supported. I think the proposal was 
to support this, but we discuss this on Friday:
"org.datanucleus.exceptions.NucleusUserException: Invocation of method 
"orElse" on "java.util.Optional" is not supported"


d) query: "optionalPC == null"
 From this comment 
(https://issues.apache.org/jira/browse/JDO-751?focusedCommentId=15154475&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15154475) 
by Craig (Feb 19, 16:44) my understanding was that this should only 
return objects with 'optionalPC==null', but _not_ objects with 
'optionalPC.isEmpty()'.
However we can discuss this on Friday.

A related problem occurs with the query "!(optionalPC == null)"
This returns only objects where 'optionalPC.get() != null'.
My understanding was that it should also return with 
'optionalPC.isEmpty()', because the reference is not actually null.

 From the post, my understanding was that we always assume 
optional-shortcut form when comparing to an actual instance, but allow 
comparison with the 'reference to Optional' when copmparing to 'null'.

Again, we can discuss this.

I'll upload a patch with the latest version.

Best,
Tilmann


On 31-May-16 20:33, Craig Russell wrote:
>> On May 31, 2016, at 3:08 AM, Tilmann Zschke <za...@gmx.de> wrote:
>>
>> Hi,
>>
>>> More likely the problem is down to having a field as Optional<Object>
>> The test doesn't actually have Optional<Object>, but it does have:
>>
>> Optional<?> optionalAny;
>> Optional optionalNoGenerics;
>>
>> I suppose these would not be allowed either (because they are mostly equivalent to Optional<Object>)?
> Yes. Optional<?> and Optional are not of much interest (to me at least).
>
> I agree with Andy that supporting Object in an object model should be sufficiently flexible. Optional<Object> does not add any value to the model.
>
> In plain English, "Object can be any object. Optional<Object> can be anything but with some special behavior about nullability"???
>
> Craig
>> Regards,
>> Tilmann
>>
>> On 31-May-16 11:53, Andy Jefferson wrote:
>>> Hi,
>>>> thanks. Indeed it seems that the error is triggered by declaring a field
>>>> as 'Optional'.
>>> That I doubt, due to established tests
>>> https://github.com/datanucleus/tests/blob/master/jdo/general/src/test/org/datanucleus/tests/types/OptionalTest.java
>>>
>>>
>>> More likely the problem is down to having a field as Optional<Object>, which is a minority interest use-case IMHO (which can often be symptomatic of a problem in a model, with lack of use of inheritance etc). Perhaps try nightly builds of jars if having problems.
>>>
>>>> Next step is likely to update the implementation.
>>> DataNucleus has supported Optional since 5.0.0-m1, and tested on Optional<{basic}>, Optional<PC> (see link). It hasn't been tested on Optional<Object> where Object refers to potentially multiple types of PC.
>>>
>>>
>>>
>>> Regards
>>
> Craig L Russell
> Architect
> craig.russell@oracle.com
> P.S. A good JDO? O, Gasp!
>
>
>
>
>