[jpa-spec users] [jsr338-experts] Re: Proposal for EntityGraphs, fetch plans, etc...

From: Rainer Kwesi Schweigkoffer <>
Date: Wed, 19 Dec 2012 12:21:52 +0100

Hi Linda, all,

Linda DeMichiel, am 9 Dec 2012 hast Du um 15:06 zum Thema "[jsr338-
experts] Re: Proposal for EntityGraphs, f" geschrieben :

> On 12/7/2012 12:01 PM, Linda DeMichiel wrote:
> > Hi Ollie,
> >
> > On 12/7/2012 10:29 AM, Oliver Gierke wrote:
> >> Am 07.12.2012 um 18:57 schrieb Gordon Yorke<>:
> >>
> >>> It was removed from an earlier draft version to reduce the clutter in the NamedEntityManager annotation as
> >>> NamedAttributeNode serves the same purpose. It also eliminates any confusion about when to use the String[] vs the
> >>> NamedAttributeNode[] and how they interact.
> >>> --Gordon
> >>
> >> I guess you mean NamedEntityGraph, right? I don't think an additional simple attribute is clutter actually. Also, I
> >> can't see any confusion as the String[] can easily be evaluated like an @NamedAttributeNode with a plain name
> >> attribute and would be added to other @NamedAttributeNode declarations. Simple rule, no corner cases. Especially in
> >> scenarios where you'd simply list a couple of Strings this would actually *reduce* clutter and complexity on the
> >> definition side. Make the simple things simple, complex things possible.
> >>
> >> The examples you showed were referring to a few properties only and already consumed quite a bit of space. Assuming
> >> real world scenarios, this overhead would even grow beyond that. It's yet another annotation per property to refer to.
> >> I'd actually would be interested in seeing an XML definition example because it feels like the annotation based
> >> definition might actually be more verbose than the XML equivalent.
> >>
> >> I strongly recommend to favor conciseness on the definition / user side of things over a few more lines of
> >> implementation code. Parts of the spec already do a suboptimal job in this regard and I think we do the users and the
> >> spec a favor if we make it as usable as possible.
> >>
> >
> > While I sympathize with your ease-of-use argument here, I do think that having 3 ways of specifying
> > attributes in NamedEntityGraph would be a bit much.
> >
> OK, I've been mulling this over some more and I have to admit I am really torn about this issue in
> view of Ollie's verbosity argument.
> Can we have some more feedback on this point, please?

I could imagine that Ollie's proposed string attributes might become as
useful as the string-based methods in the Criteria API.

Just my Euro 0.02

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       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 
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