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