Kevin, The only use case I can think of is the obvious one: a mapping system more expressive and typesafe than xml, while allowing for refactoring and clutter-free entity code. However--and this is just coming off the top of my head as I'm writing--I wonder if there might be needs to compute mappings based on dynamic criteria rather than be bound to compiled annotations or static xml (of course, I can't think of what those needs are at the moment).
On Tue, May 11, 2010 at 12:21 PM, Kevin Sutter <[email protected]> wrote: > Hi Christopher, > Now I see what you meant by a "fluent API"... To be honest, my viewpoint > of > this API was to allow for an alternate means of configuring Hibernate, > other > than just using XML. Classic Hibernate only supported configuration > through > XML, so this fluentHibernate allowed for a programming-based mechanism for > configuration. On the surface, it seems like this would be more difficult > to use than just using annotations. > > Can you provide any use cases in the JPA sense that would describe how this > type of configuration API would be helpful? > > On a similar vein, we are considering an API to help with configuration of > the persistence unit. Since the persistence unit is defined by the > persistence.xml only, allowing some alternate means via an API would be > welcome. > > Kevin > > On Tue, May 11, 2010 at 10:27 AM, Christopher Gardner < > [email protected]> wrote: > > > Thanks. I'm in the former camp, i.e., a legacy database. I'm aware of > the > > xml alternative. Though I'm no DotNet developer, I read about an Fluent > > NHibernate, which allows you to create a object to store mapping in code. > > > > http://wiki.fluentnhibernate.org/Getting_started > > > > <http://wiki.fluentnhibernate.org/Getting_started>Maybe such an API > isn't > > appropriate for a spec, but it would be an interesting alternative to > both > > annotations and xml for JPA. > > > > On Tue, May 11, 2010 at 11:21 AM, Kevin Sutter <[email protected]> > wrote: > > > > > Hi Christopher, > > > You're right, annotations can be verbose. But, they don't have to be. > > It > > > all depends on whether your application can live with the default > > > processing > > > defined by the spec. We tried to pick the most common default values > for > > > the various annotation elements. If your application can live with the > > > default processing, then all that is really necessary is the @Entity > and > > > @Id > > > annotations. But, most legacy applications and schemas can not live > with > > > the default settings, thus the annotations can become verbose. > > Flexibility > > > can be a killer... But, then we'd be crucified if we didn't allow for > > the > > > flexibility... :-) > > > > > > The annotations can also be overridden via orm.xml declarations. This > > > would > > > keep your base code more readable, while putting the detailed gorp into > > the > > > xml file(s). Maybe this would be more suitable for your environment. > > > > > > Not sure what you mean by "fluent API". Any specific examples to help > > with > > > this discussion? > > > > > > Thanks, > > > Kevin > > > > > > On Tue, May 11, 2010 at 10:10 AM, Christopher Gardner < > > > [email protected]> wrote: > > > > > > > Vis-a-vis all JPA specs, streamlining annotations would be nice. The > > > > annotations can be verbose. Maybe a fluent API would be in order. > > > > > > > > On Tue, May 11, 2010 at 10:46 AM, Kevin Sutter <[email protected]> > > > wrote: > > > > > > > > > Hi Chris, > > > > > Sorry to hear that you are frustrated with JPA 2.0. Can you > > elaborate? > > > > > The > > > > > JPA Expert Group is currently soliciting feedback for the next > > revision > > > > of > > > > > the JPA spec (2.x or 3.0). Here's the e-mail address for this > > > > > correspondence [1]. But, if there are distinct improvements that > are > > > you > > > > > looking for, maybe they could be entertained by the OpenJPA > community > > > > > first. Bugs and/or Features can be entered into our JIRA system > [2] > > > for > > > > > future consideration. Of course, community involvement can help > > speed > > > up > > > > > this process. > > > > > > > > > > Thanks for the input, > > > > > Kevin > > > > > > > > > > [1] [email protected] > > > > > [2] https://issues.apache.org/jira/browse/OPENJPA > > > > > > > > > > On Tue, May 11, 2010 at 9:12 AM, C N Davies <[email protected]> > > wrote: > > > > > > > > > > > I'm so frustrated by JPA 2.0 but can't seem to find an JSR for > JPA > > 3 > > > or > > > > > > anything. Can anyone point me it? > > > > > > > > > > > > > > > > > > > > > > > > Thanks J > > > > > > > > > > > > > > > > > > > > > > > > Chris > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
