openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevin Sutter <kwsut...@gmail.com>
Subject Re: JPA 3.0
Date Wed, 12 May 2010 15:06:10 GMT
Hi Matthew,
I can agree with the idea of dynamically generating classes at runtime and
be able to persist them and use them in queries.  But, the dynamic
generation of mappings makes me go tilt.  :-)

Kevin

On Wed, May 12, 2010 at 9:56 AM, Matthew Adams <matthew@matthewadams.me>wrote:

> I don't think the intent is to be able to dynamically change mappings,
> although I suppose that's certainly possible.  The primary use case
> for the metadata API is to be able to generate classes at runtime and
> be able to persist them.  I didn't follow the metadata API
> justification email thread too closely, so there may be other reasons
> to have it.
>
> -matthew
>
> On Wed, May 12, 2010 at 6:35 AM, Kevin Sutter <kwsutter@gmail.com> wrote:
> > 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 <
> > chris.r.gardner@gmail.com> 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 <kwsutter@gmail.com>
> 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 <
> >> > chris.r.gardner@gmail.com> 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 <kwsutter@gmail.com>
> >> > 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 <
> >> > > > chris.r.gardner@gmail.com> 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 <
> kwsutter@gmail.com
> >> >
> >> > > > 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]  jsr-317-feedback@sun.com
> >> > > > > > [2]  https://issues.apache.org/jira/browse/OPENJPA
> >> > > > > >
> >> > > > > > On Tue, May 11, 2010 at 9:12 AM, C N Davies <cnd@cndavies.com
> >
> >> > > 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
> >> > > > > > >
> >> > > > > > >
> >> > > > > > >
> >> > > > > > >
> >> > > > > >
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
> >
>
>
>
> --
> mailto:matthew@matthewadams.me
> skype:matthewadams12
> yahoo:matthewadams
> aol:matthewadams12
> google-talk:matthewadams12@gmail.com<google-talk%3Amatthewadams12@gmail.com>
> msn:matthew@matthewadams.me <msn%3Amatthew@matthewadams.me>
> http://matthewadams.me
> http://www.linkedin.com/in/matthewadams
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message