Hi Christopher, Hmmm... Interesting idea, but is this dynamic mapping really practical? It sounds like you are looking for the means to dynamically create or change the mappings defined by your Entity and your database Schema. The attribute types in your Entity definitions will need to match (or at least easily convert to) the types in your database Schema. Since most customer database schemas are fairly static, I don't quite see the need for dynamic mappings.
Maybe I need another cup of coffee this morning, but I'd still be interested in hearing a specific, real-world use case where the mappings between your Entity and Schema need to be dynamic. Thanks, Kevin On Tue, May 11, 2010 at 11:33 AM, Christopher Gardner < [email protected]> wrote: > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
