Hi Rainer,
Thanks for the helpful comments. More inline below....
On 2/20/2013 5:25 AM, Rainer Kwesi Schweigkoffer wrote:
> Hi Linda,
>
> Linda DeMichiel, am 18 Feb 2013 hast Du um 13:59 zum Thema "[jsr338-
> experts] new spec draft (PFD candidate) a" geschrieben :
>
>> I've just uploaded a new spec draft and orm.xsd file to our project
>> downloads area: http://java.net/projects/jpa-spec/downloads
>>
>> These reflect the recent updates to the foreign key metadata.
>>
>> I would like to submit this draft (or something very close to it)
>> to the JCP at the end of the week as the JPA 2.1 Proposed Final Draft.
>>
>> Please let me know if you find any issues.
>
> thanks a lot for the tremendous work that you have put into this draft.
> Please allow me for some minor comments:
>
>
> 3.7 3rd paragraph p. 108
>
> construst -> construct
>
fixed
>
> 3.7.1 javadoc of addKeySubgraph 1st paragraph p. 110
>
> "Use of ... to the graph". Given the general remark in the 2nd
> paragraph of the javadoc of the interface on p. 109, and in consistence
> with the other javadocs of addKeySubgraph this sentence should be
> removed, shouldn't it?
>
yes -- gone
>
> 3.7.3 javadoc of getClassType p.116
>
> Would expect something like "Return the java class of the managed type
> for which ...".
>
fixed
>
> 3.7.4.2 pp. 119 - 121
>
> Would it make sense to consistently replace "fetch" by "load"
> throughout this section?
>
fetch is used generically here, so I changed consistently to that.
>
> 3.10.2 javadoc of setLockMode throws clause p. 138
>
> Criteria API query -> CriteriaQuery query
>
fixed
>
> 7.4 javadoc of addNamedEntityGraph p. 338
>
> A remark on the (non-)effect on already created mutable copies (similar
> to the addNamedQuery javadoc) might be helpful.
>
I was going to add something here, but decided not to, as I think the
existing docs are sufficiently clear about the (im)mutability of what is
stored/returned
>
> 9.4 p. 384 2nd bullet last sentence
>
> I believe to remember a discussion on whether both script targets need
> to be set even if the action (either create or drop) triggers only one
> script to be created, but the current wording of the spec is not clear
> enough to me to understand what the outcome of the discussion has been.
>
Changed to: "A script will only be generated if the script target is specified."
Which begs the question of what happens if drop-and-create is specified, but
only one script supplied. I've left that as undefined. It might result in
a deployment error, for example.
>
> 11.2.1.1 2nd paragraph 2nd sentence p. 491
>
> in -> is
>
fixed
>
> Best regards
> Rainer
>
Thanks again
best regards
-Linda
>
>
> ---
> Rainer Schweigkoffer SAP AG Walldorf
> Regulatory Compliance TIP Core JI
> Core Java Infrastructure Dietmar-Hopp-Allee 16
> Technology& Innovation Platform D-69190 Walldorf
> Building 3, F.3.14 phone: +49 6227 7 45305
> rainer.schweigkoffer_at_sap.com fax: +49 6227 7 821177
>
> Sitz der Gesellschaft/Registered Office: Walldorf, Germany
> Vorstand/SAP Executive Board: Werner Brandt, Lars
> Dalgaard, Luisa Deplazes Delgado, Bill McDermott (Co-CEO),
> Gerhard Oswald, Vishal Sikka, Jim Hagemann Snabe (Co-CEO)
> Vorsitzender des Aufsichtsrats/Chairperson of the SAP
> Supervisory
> Board: Hasso Plattner
> Registergericht/Commercial Register Mannheim No HRB 350269
>
> Diese E-Mail kann Betriebs- oder Geschaeftsgeheimnisse
> oder sonstige vertrauliche Informationen enthalten.
> Sollten Sie diese E-Mail irrtuemlich erhalten haben, ist
> Ihnen eine Verwertung des Inhalts, eine Vervielfaeltigung
> oder Weitergabe der E-Mail ausdruecklich untersagt. Bitte
> benachrichtigen Sie uns und vernichten Sie die empfangene
> E-Mail. Vielen Dank.
>
> This e-mail may contain trade secrets or privileged,
> undisclosed, or otherwise confidential information. If you
> have received this e-mail in error, you are hereby
> notified that any review, copying, or distribution of it
> is strictly prohibited. Please inform us immediately and
> destroy the original transmittal. Thank you for your
> cooperation.
>
>