Re: EJBQL: question about state fields of an embedded class type
Hi Mike,
thanks for the update.
Regards Michael
> Hi Michael,
>
> Linda and I were actually talking yesterday about this and my
> conclusion is that at this stage we should not add extra support
> for embedded objects. I had initially expected to have this, but
> based on where we are now, and the time frame, I think that we may
> have to defer this to the next release. For now I think the portable
> way of selecting and comparing will have to be to use the embedded
> state fields.
>
> -Mike
>
>
>>-----Original Message-----
>>From: Michael Bouschen [mailto:Michael.Bouschen_at_Sun.COM]
>>Sent: Thursday, January 19, 2006 1:11 PM
>>To: persistence_at_glassfish.dev.java.net; Mike Keith
>>Cc: Shelly.McGowan_at_Sun.COM
>>Subject: Re: EJBQL: question about state fields of an embedded class
>>type
>>
>>
>>Hi Linda, hi Mike,
>>
>>is there any update on more support for embeddeds in EJBQL
>>(in addition
>>to navigating through embeddeds)?
>>
>>Thanks!
>>
>>Regards Michael
>>
>>
>>>I don't recall discussion of direct comparison of embeddeds.
>>>Otherwise we also would have needed to have added
>>>rules for such comparisons (e.g., in the presence of
>>>serialized fields, nulls, etc. as well).
>>>
>>>Comparison of embeddeds would be useful, but we don't
>>>otherwise provide first-class support for embeddeds in
>>>the query language, so we should look at the other cases
>>>if we open this discussion. For example, right now we don't
>>>cover support for embeddeds in select lists, COUNT, GROUP BY,
>>>UPDATE, etc.
>>>
>>>I think it would be good to do this. (and I think it
>>>would be better than just restricting to comparisons).
>>> From a BNF point of view, I believe it would also be
>>>the simplest thing to do.
>>>
>>>Michael, Shelly what would the impact be (assuming you
>>>don't cover this already ??)?
>>>
>>>thanks,
>>>
>>>Linda
>>>
>>>
>>>Mike Keith wrote:
>>>
>>>
>>>>Hi,
>>>>
>>>>Yes, we did intend to allow comparison of embedded objects
>>
>>as outlined
>>
>>>>in 4.4.4, but the grammar does not seem to have been updated to
>>>>reflect it. We will either have to modify the grammar or
>>
>>change 4.4.4
>>
>>>>to back out of the embedded object comparison support.
>>>>
>>>>Depending on how messy it makes the EJB QL grammar we may
>>
>>choose to pull
>>
>>>>back the embedded comparison from EJB QL since there is always a
>>>>workaround of navigating through the embedded object to
>>
>>the embedded
>>
>>>>state fields. (Linda, we might want to check with the
>>
>>group on this
>>
>>>>question, though.)
>>>>
>>>>-Mike
>>>>
>>>>
>>>>
>>>>>-----Original Message-----
>>>>>From: Linda DeMichiel [mailto:Linda.Demichiel_at_Sun.COM]
>>>>>Sent: Tuesday, January 03, 2006 10:48 AM
>>>>>To: Michael Bouschen
>>>>>Cc: Mike Keith; persistence_at_glassfish.dev.java.net
>>>>>Subject: Re: EJBQL: question about state fields of an
>>
>>embedded class
>>
>>>>>type
>>>>>
>>>>>
>>>>>Michael,
>>>>>
>>>>>Happy new year!
>>>>>
>>>>>Michael, Your understanding of how it is defined
>>>>>is correct.
>>>>>
>>>>>Mike, what do you think -- should we extend this
>>>>>to support direct comparison of embedded objects,
>>>>>or hold off?
>>>>>
>>>>>Linda
>>>>>
>>>>>
>>>>>Michael Bouschen wrote:
>>>>>
>>>>>
>>>>>
>>>>>>Hi Linda, hi Mike,
>>>>>>
>>>>>>Happy New Year!
>>>>>>
>>>>>>I have a question about embedded objects in EJBQL: does
>>
>>EJBQL allow
>>
>>>>>>comparing of embedded objects? Suppose class Customer
>>
>>has a property
>>
>>>>>>embeddedCountry annotated as @Embedded of @Embeddable type
>>>>>>EmbeddedCountry. The following EJBQL query compare the
>>>>>
>>>>>
>>>>>property with a
>>>>>
>>>>>
>>>>>>parameter:
>>>>>> SELECT c FROM Customer c WHERE c.embeddedCountry = :param
>>>>>>
>>>>>>I read chapter 4.4.4 Path Expressions that I can
>>
>>navigate through an
>>
>>>>>>embedded object. But a path expression must end in a simple
>>>>>
>>>>>
>>>>>state-field
>>>>>
>>>>>
>>>>>>which cannot refer an embedded object. Is this correct?
>>>>>
>>>>>
>>>>>Then the above
>>>>>
>>>>>
>>>>>>query would not be valid.
>>>>>>
>>>>>>Regards Michael
>>>>>
>>>>>
>>