You are viewing a plain text version of this content. The canonical link for it is here.

Posted to users@openjpa.apache.org by C N Davies <cn...@cndavies.com> on 2010/05/11 16:12:17 UTC

JPA 3.0

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

Re: JPA 3.0

Posted by Kevin Sutter <kw...@gmail.com>.

Hi Chris,
Fairly loaded response...  :-)  As with any "new" technology, some features
of past technologies will still be missing.  Some of these features are
skipped on purpose (let's see if these are really required), others are
still on the plate but couldn't contain in the current release, and others
are just accidentally missed.

As you pointed out, many of these short-comings are due to the "design by
committee" approach.  But, just to defend the process a bit, I will say that
the JPA Expert Group actually worked quite well together.  The primary
voices were IBM, Oracle/Sun, Hibernate, and SAP.  Depending on the specific
feature being discussed, various members took the spotlight and drove that
feature.  But, everybody had a voice.  There was not a single, prominent
member that drove the spec (like I've heard of other specs).

Given that introduction, I'll provide a bit more response to your individual
paragraphs below...

And, I would suggest that if you feel strongly about any of these JPA
concerns, please post them to the JSR 317 feedback mailing list.  Thanks!

Thanks,
Kevin

On Tue, May 11, 2010 at 11:06 AM, C N Davies <cn...@cndavies.com> wrote:

> Thanks Kevin,
>
> I'll take a look and happy to get involved rather than bitch from the
> sidelines, I hate people who do that! :)
>
> My issues are frankly not bugs,  just what I'd term "Committee design
> decisions"  one of the down sides of the community process.  I know at
> least
> 5 people specifically who stopped using  OpenJPA blaming Apache when it's
> the JPA spec.  Number one frustration is the entity state,  who cares how
> JPA manages the entity, it should be transparent to the developer, we
> develop applications and use a database because it knows how to be a
> database. Why do I have to implement functionality to check if my entity is
> detached and handle it accordingly? Record and field level locking were
> well
> implemented in my first CPM ISAM file based experience using Canon Basic
> back, or SVR 4 in the 80's. I still use a DOS based Btrieve TSR for a huge
> POS system I developed about 20 years ago that seems to be able to handle
> these things transparently.
>

It's a matter of flexibility.  There are many client/server applications
that do not require the constant persistence context association.  Knowing
when it is okay and not okay to assume database availability is necessary
for best efficiency.  Both from an application viewpoint as well as from the
JPA runtime perspective.  I do agree that some of the processing gets
confusing depending on whether the Entity state is detached or not.  But, it
does provide much flexibility for the various applications that use the JPA
technology.

>
> JPA 2.0 "group by" rules were clearly designed by a DBA or Debian puritan,
> Oracle, MSSQL, MySQL and DB2 seem to be able to handle group by statement
> not including the all aggregated fields in the select statement, yet JPA 2
> requires it.  IMHO it should be a configuration property. If your Debian
> MySQL instance tries to force you to use it then turn it on, if you company
> DBA requires you to use it, then turn it on. If not the spec should allow
> you to turn it off.
>

:-)  I will agree that some of the expert group members are more DBA-like
than I am.  I kind of get pigeon-holed into DB2 capabilities, but other
members make sure that the solution is more generic and usable by other
database vendors.  The whole "pessimistic locking" mechanism was also
difficult to design by committee due to the differences in database
capabilities.  This particular "group by" concern would be an excellent
feedback item for the expert group.

>
> Fetch groups,  great idea but the surely JPA should be smart enough to work
> out that my lazy loaded collection should still be lazy loaded even is I
> call "size()"  on the lazy loaded collection. Instead I have to maintain a
> separate field in my enclosing entity and keep it in sync with the actual
> size of the lazy loaded collection, so it can actually be lazy loaded.
> Basically regress the quality of my design to what I would have done about
> 20 years ago.
>

I'm assuming you are referring to the OpenJPA Fetch Groups now (not specific
to a JPA spec feature).  This particular problem is something that should be
addressed via an OpenJPA JIRA.

>
> Having used commercial ORMS implementations for eh last 10 years,  JPA is
> very limited. Here's an example of how I can do it right now in a
> commercial
> app.
>
>
> Entity ent = Main.getSession().get(Class, Object[] keys);
> ....
> Do something with it
> ....
> Main.getSession().put(ent);
>
>
> Looks like JPA,  but notice I don't have to create an entity manager, I
> don't have to check if I have to merge or not,  don't have to check the
> attachment state. I can give it to a grad and he/she can use the paradigm.
> I don't have to constantly create and close entity managers all over the
> place. I guess the basic idea is that IMHO JPA 3 should be based more
> around
> an application model so the developer instantiates a persistence session
> that is application global and the JPA implementation manages the
> persistence.
>

In a way, your getSession() corresponds to an EM.  But, in this example, you
would have to maintain the lifecycle of the EM.  Running in a Container
environment simplifies this greatly.  The EM could be automatically injected
and associated with the transaction context.  And, the merge() method can be
used for both new and updated Entities.

>
> So far I have not been convinced that EJB 3 had done much more than save
> the
> developer writing a few queries, but what I can tell you it has increased
> our development costs significantly, as we have to redesign apps and
> developers spend more crazy amounts of time trying to get JPA 3 to deliver
> similar performance and functionality as EJB 2. We actually turned a major
> project around mid way through our development schedule to get off JPA and
> go back to native Hibernate and basic JDBC.
>

That's not a good promotion for JPA...  :-(  We have actually heard the
opposite from customers moving from more specific JDBC applications.  If
customers are currently writing their own SQL and JDBC calls, the move to
JPA is very much welcome.  Hides all of that gorp of interacting with the
database and fluffing up the result sets is something that JPA helps with
greatly.  Especially if you are using multiple databases.

We have done many, many improvements to the OpenJPA runtime to help with
performance.  Comparing the JPA runtime to JDBC is still tough, but we are
very close.  All of our benchmarks comparing to EJB 2 have never shown EJB 2
performing better than JPA.  But, with all benchmarks, it all depends on the
application.  We do many of our benchmark comparisons using DayTrader and
SpecJApp.  The most recent SpecJApp results with WebSphere and the JPA 2.0
Feature Pack (which uses OpenJPA 2.0) are quite impressive [1].

[1]
http://www.spec.org/jEnterprise2010/results/res2010q2/jEnterprise2010-20100407-00010.html
      http://www.spec.org/jEnterprise2010/results/jEnterprise2010.html

>
> OK I'll get off ny soap box now.
>

Me too...  :-)

Take care,
Kevin

>
> Chris
>
>
>
>
> -----Original Message-----
> From: Kevin Sutter [mailto:kwsutter@gmail.com]
> Sent: Wednesday, 12 May 2010 1:22 AM
> To: users@openjpa.apache.org
> Subject: Re: JPA 3.0
>
> 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 <kw...@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 <cn...@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
> > > >
> > > >
> > > >
> > > >
> > >
> >
>
>

Re: JPA 3.0

Posted by Daniel Toffetti <dt...@yahoo.com.ar>.


Daryl Stultz-2 wrote:
> 
> On Fri, Jun 25, 2010 at 8:46 PM, Daniel Toffetti
> <dt...@yahoo.com.ar>wrote:
>>
>>    Some time ago I started a quest for a magic tool,
>>    Thanks in advance for any useful tool or URL I might have missed.
> 
> I don't know exactly what you are looking for, but if you haven't looked
> at it, try Ebean. It's pretty flexible with mixing "ORM queries" with
> raw/native SQL.
> 
> http://www.avaje.org/
> 
> -- 
> Daryl Stultz
> 

    I stumbled on this site a couple of times, it seemed too similar to JPA
then, but now I've taken a closer look at the docs and it seems to have some
good points in favor.
    First, it supports all the JPA annotations so using it is somewhat close
to standards. Second, it implements a different entity lifecycle (but still
within the limits of the JPA spec), so I can have detached entities.
    So perhaps I'm very close to my ideal tool.
    I appreciate very much your help, thanks !!!



Russell Collins wrote:
> 
> I have never tried to use JPA with Stored Procedures so excuse my
> ignorance.  If it is difficult or not available, it would benefit the spec
> if JPA would easily use stored procedures and views just like it uses
> tables.  The only thing I think would need to be added to a marked-up
> Entity Object is something like a stored procedure input annotation. 
> Example:
> 
> @Column(name = "admid", nullable=false, length=10)
> @Id
> @ProcedureInput(procedurename = "sp1" name = "somename1", length =  10)
> @ProcedureInput(procedurename = "sp2" name = "somename2", length =  10)
> private String id;
> 
> Just a suggestion.  Hopefully it can spark some good discussion.
> 

    EclipseLink has some non-standard annotations to help in calling stored
procs:

http://wiki.eclipse.org/Using_EclipseLink_JPA_Extensions_%28ELUG%29#Using_EclipseLink_JPA_Extensions_for_Stored_Procedure_Query

    They are non-standard but perhaps, being already supported by
EclipseLink, they are considered in a future JPA release.
    The main problem with this is that using stored procedures contradicts
the nature of ORM. An SP can modify some live or cached entities,
invalidating them.
    Now EBean (the library suggested by Daryl), being somewhat different in
regards to native operations in the database, offers some support for
hinting what entities might have changed externally (see ebeans 
user guide, section 9.5), so the tool takes care of cached entities
properly.

    In the end, I believe there are two different philosophies and
attempting to make use of both at the same time can become increasingly
tricky.

Thanks for your help,

Daniel

-- 
View this message in context: http://openjpa.208410.n2.nabble.com/JPA-3-0-tp5036154p5232846.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.

Re: JPA 3.0

Posted by Daryl Stultz <da...@opentempo.com>.

On Fri, Jun 25, 2010 at 8:46 PM, Daniel Toffetti <dt...@yahoo.com.ar>wrote:

>
>
>    Some time ago I started a quest for a magic tool,


>    Thanks in advance for any useful tool or URL I might have missed.
>
> I don't know exactly what you are looking for, but if you haven't looked at
it, try Ebean. It's pretty flexible with mixing "ORM queries" with
raw/native SQL.

http://www.avaje.org/

-- 
Daryl Stultz
_____________________________________
6 Degrees Software and Consulting, Inc.
http://www.6degrees.com
http://www.opentempo.com
mailto:daryl.stultz@opentempo.com

RE: JPA 3.0

Posted by Russell Collins <Ru...@mclaneat.com>.

I have never tried to use JPA with Stored Procedures so excuse my ignorance.  If it is difficult or not available, it would benefit the spec if JPA would easily use stored procedures and views just like it uses tables.  The only thing I think would need to be added to a marked-up Entity Object is something like a stored procedure input annotation.  Example:

@Column(name = "admid", nullable=false, length=10)
@Id
@ProcedureInput(procedurename = "sp1" name = "somename1", length =  10)
@ProcedureInput(procedurename = "sp2" name = "somename2", length =  10)
private String id;


Just a suggestion.  Hopefully it can spark some good discussion.

-----Original Message-----
From: Daniel Toffetti [mailto:dtoffe@yahoo.com.ar]
Sent: Friday, June 25, 2010 7:46 PM
To: users@openjpa.apache.org
Subject: RE: JPA 3.0


Hi,

    Sorry I'm late but I don't want to miss this party... :-)
    I want to join Chris in his feelings, but pointing out that perhaps what
I would most likely want to see is a JDBC 5 rather than a JPA 3.
    I'll try to be more specific:
- I agree I'm not interested in the entity state, I just want detached
entities.
- I don't want to configure mappings, I just want table rows as objects,
anemic model is what some people call it. If there is a tool that can
generate the corresponding Java code, better yet.
- I don't want to write JDBC boilerplate code, things like Spring JDBC
templates or similar would be appreciated (but without Spring !).
- Our databases make heavy use of stored procedures, setting IN params,
getting OUT params and a list of entities should be trivial. Spring SP
templates comes to mind (but without Spring !).

    Some time ago I started a quest for a magic tool, I searched
SourceForge, GoogleCode, FreshMeat and Kenai for keywords like SQL, JDBC,
JPA, DAO, ORM, Stored Procedure, etc. I've found and downloaded about eighty
projects, most with source code, most barely useable. Some of them attempt
to avoid OR mapping, some attempt to do it but better. Data access tools and
libraries pop everywhere you move a rock, I guess this says something about
the situation.

    The first time I learnt about ORM, I got scared and horrified... like,
"you mean no SPs ?"  I've come to understand the scenarios where ORM and JPA
have its place, I don't think JPA is faulty.
    It's just that I want something different, some tool that assumes I'm
working with an RDBMS and want to use it as such.

    Thanks in advance for any useful tool or URL I might have missed.

Cheers,

Daniel

--
View this message in context: http://openjpa.208410.n2.nabble.com/JPA-3-0-tp5036154p5224183.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.

CONFIDENTIALITY NOTICE: The information contained in this electronic mail (email) transmission (including attachments), is intended by MCLANE ADVANCED TECHNOLOGIES for the use of the named individual or entity to which it is addressed and may contain information that is privileged, confidential and/or protected as a trade secret. It is not intended for transmission to, or receipt by, any individual or entity other than the named addressee(s). If you have received this email in error, please delete it (including attachments) and any copies thereof without printing, copying or forwarding it, and notify the sender of the error by email reply immediately.

RE: JPA 3.0

Posted by Daniel Toffetti <dt...@yahoo.com.ar>.

Hi,

Sorry I'm late but I don't want to miss this party... :-)
I want to join Chris in his feelings, but pointing out that perhaps what
I would most likely want to see is a JDBC 5 rather than a JPA 3.
I'll try to be more specific:
- I agree I'm not interested in the entity state, I just want detached
entities.
- I don't want to configure mappings, I just want table rows as objects,
anemic model is what some people call it. If there is a tool that can
generate the corresponding Java code, better yet.
- I don't want to write JDBC boilerplate code, things like Spring JDBC
templates or similar would be appreciated (but without Spring !).
- Our databases make heavy use of stored procedures, setting IN params,
getting OUT params and a list of entities should be trivial. Spring SP
templates comes to mind (but without Spring !).

Some time ago I started a quest for a magic tool, I searched
SourceForge, GoogleCode, FreshMeat and Kenai for keywords like SQL, JDBC,
JPA, DAO, ORM, Stored Procedure, etc. I've found and downloaded about eighty
projects, most with source code, most barely useable. Some of them attempt
to avoid OR mapping, some attempt to do it but better. Data access tools and
libraries pop everywhere you move a rock, I guess this says something about
the situation.

The first time I learnt about ORM, I got scared and horrified... like,
"you mean no SPs ?" I've come to understand the scenarios where ORM and JPA
have its place, I don't think JPA is faulty.
It's just that I want something different, some tool that assumes I'm
working with an RDBMS and want to use it as such.

Thanks in advance for any useful tool or URL I might have missed.

Cheers,

Daniel

--
View this message in context: http://openjpa.208410.n2.nabble.com/JPA-3-0-tp5036154p5224183.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.

RE: JPA 3.0

Posted by C N Davies <cn...@cndavies.com>.

Thanks Kevin,

I'll take a look and happy to get involved rather than bitch from the
sidelines, I hate people who do that! :)

My issues are frankly not bugs,  just what I'd term "Committee design
decisions"  one of the down sides of the community process.  I know at least
5 people specifically who stopped using  OpenJPA blaming Apache when it's
the JPA spec.  Number one frustration is the entity state,  who cares how
JPA manages the entity, it should be transparent to the developer, we
develop applications and use a database because it knows how to be a
database. Why do I have to implement functionality to check if my entity is
detached and handle it accordingly? Record and field level locking were well
implemented in my first CPM ISAM file based experience using Canon Basic
back, or SVR 4 in the 80's. I still use a DOS based Btrieve TSR for a huge
POS system I developed about 20 years ago that seems to be able to handle
these things transparently.

JPA 2.0 "group by" rules were clearly designed by a DBA or Debian puritan,
Oracle, MSSQL, MySQL and DB2 seem to be able to handle group by statement
not including the all aggregated fields in the select statement, yet JPA 2
requires it.  IMHO it should be a configuration property. If your Debian
MySQL instance tries to force you to use it then turn it on, if you company
DBA requires you to use it, then turn it on. If not the spec should allow
you to turn it off.

Fetch groups,  great idea but the surely JPA should be smart enough to work
out that my lazy loaded collection should still be lazy loaded even is I
call "size()"  on the lazy loaded collection. Instead I have to maintain a
separate field in my enclosing entity and keep it in sync with the actual
size of the lazy loaded collection, so it can actually be lazy loaded.
Basically regress the quality of my design to what I would have done about
20 years ago.

Having used commercial ORMS implementations for eh last 10 years,  JPA is
very limited. Here's an example of how I can do it right now in a commercial
app.

Entity ent = Main.getSession().get(Class, Object[] keys);
....
Do something with it
....
Main.getSession().put(ent);

Looks like JPA,  but notice I don't have to create an entity manager, I
don't have to check if I have to merge or not,  don't have to check the
attachment state. I can give it to a grad and he/she can use the paradigm.
I don't have to constantly create and close entity managers all over the
place. I guess the basic idea is that IMHO JPA 3 should be based more around
an application model so the developer instantiates a persistence session
that is application global and the JPA implementation manages the
persistence. 

So far I have not been convinced that EJB 3 had done much more than save the
developer writing a few queries, but what I can tell you it has increased
our development costs significantly, as we have to redesign apps and
developers spend more crazy amounts of time trying to get JPA 3 to deliver
similar performance and functionality as EJB 2. We actually turned a major
project around mid way through our development schedule to get off JPA and
go back to native Hibernate and basic JDBC.

OK I'll get off ny soap box now.

Chris

-----Original Message-----
From: Kevin Sutter [mailto:kwsutter@gmail.com] 
Sent: Wednesday, 12 May 2010 1:22 AM
To: users@openjpa.apache.org
Subject: Re: JPA 3.0

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 <kw...@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 <cn...@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
> > >
> > >
> > >
> > >
> >
>

Re: JPA 3.0

Posted by Kevin Sutter <kw...@gmail.com>.

Hi Laird,
The links must just be you...  :-)  I can read them okay.

Yes, extending the Metamodel API to get access to the mapping information
was definitely on our plate for JPA 2.0, but we just ran out of runway to
complete this aspect.  This is definitely on our plate for the next
go-around.  Thanks for the input.

Kevin

On Tue, May 11, 2010 at 10:30 AM, ljnelson <lj...@gmail.com> wrote:

>
> (Perhaps it's just me; all the links in Kevin's original post are garbled
> (begin with http://user/...?), so I'll dump a quick suggestion here.)
>
> I would love a way for the EntityManager to be able to get mapping
> information in much the same way as the Metamodel API allows you to get
> type
> information.
>
> Obviously looking for annotations is only half the battle, as they could be
> overridden or replaced by orm.xml.
>
> All providers of course have a way of doing this already; seems like a nice
> thing to standardize.
>
> Best,
> Laird
>
> On Tue, May 11, 2010 at 11:22 AM, Kevin Sutter [via OpenJPA] <
> ml-node+5036522-1621461259-210534@n2.nabble.com<ml...@n2.nabble.com>
> <ml...@n2.nabble.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 <
> > [hidden email] <http://user/SendEmail.jtp?type=node&node=5036522&i=0>>
> > 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 <[hidden email]<
> http://user/SendEmail.jtp?type=node&node=5036522&i=1>>
> > 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]  [hidden email]<
> http://user/SendEmail.jtp?type=node&node=5036522&i=2>
> > > > [2]  https://issues.apache.org/jira/browse/OPENJPA
> > > >
> > > > On Tue, May 11, 2010 at 9:12 AM, C N Davies <[hidden email]<
> http://user/SendEmail.jtp?type=node&node=5036522&i=3>>
> > 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
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > >
> >
> >
> > ------------------------------
> >  View message @
> > http://openjpa.208410.n2.nabble.com/JPA-3-0-tp5036154p5036522.html
> > To start a new topic under OpenJPA Users, email
> > ml-node+208411-553807638-210534@n2.nabble.com<ml...@n2.nabble.com>
> <ml...@n2.nabble.com>
> >
> > To unsubscribe from OpenJPA Users, click here< (link removed) =>.
> >
> >
> >
>
> --
> View this message in context:
> http://openjpa.208410.n2.nabble.com/JPA-3-0-tp5036154p5036578.html
> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>

Re: JPA 3.0

Posted by ljnelson <lj...@gmail.com>.

(Perhaps it's just me; all the links in Kevin's original post are garbled
(begin with http://user/...?), so I'll dump a quick suggestion here.)

I would love a way for the EntityManager to be able to get mapping
information in much the same way as the Metamodel API allows you to get type
information.

Obviously looking for annotations is only half the battle, as they could be
overridden or replaced by orm.xml.

All providers of course have a way of doing this already; seems like a nice
thing to standardize.

Best,
Laird

On Tue, May 11, 2010 at 11:22 AM, Kevin Sutter [via OpenJPA] <
ml-node+5036522-1621461259-210534@n2.nabble.com<ml...@n2.nabble.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 <
> [hidden email] <http://user/SendEmail.jtp?type=node&node=5036522&i=0>>
> 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 <[hidden email]<http://user/SendEmail.jtp?type=node&node=5036522&i=1>>
> 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]  [hidden email]<http://user/SendEmail.jtp?type=node&node=5036522&i=2>
> > > [2]  https://issues.apache.org/jira/browse/OPENJPA
> > >
> > > On Tue, May 11, 2010 at 9:12 AM, C N Davies <[hidden email]<http://user/SendEmail.jtp?type=node&node=5036522&i=3>>
> 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
> > > >
> > > >
> > > >
> > > >
> > >
> >
>
>
> ------------------------------
>  View message @
> http://openjpa.208410.n2.nabble.com/JPA-3-0-tp5036154p5036522.html
> To start a new topic under OpenJPA Users, email
> ml-node+208411-553807638-210534@n2.nabble.com<ml...@n2.nabble.com>
> To unsubscribe from OpenJPA Users, click here< (link removed) =>.
>
>
>

-- 
View this message in context: http://openjpa.208410.n2.nabble.com/JPA-3-0-tp5036154p5036578.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.

Re: JPA 3.0

Posted by Matthew Adams <ma...@matthewadams.me>.

On Tue, May 18, 2010 at 7:17 AM, Kevin Sutter <kw...@gmail.com> wrote:
> Hi Jean-Baptiste,
> I'm with you on this aspect.  Producing the .java files, building them, and
> then using them in a JVM seems to be a more logical means of accomplishing
> this task.

OpenJPA, BTW, also supports something that might satisfy this scenario
a little better:  managed interfaces.  If you don't bother with
putting behavior in your classes and only use them as anaemic domain
model objects (see
http://martinfowler.com/bliki/AnemicDomainModel.html), you can define
your object model in terms of interfaces instead of classes and
OpenJPA will provide generated implementations of those interfaces at
runtime.  See

http://openjpa.apache.org/builds/2.0.0/apache-openjpa-2.0.0/docs/manual/ref_guide_pc_interfaces.html

Note that this feature is not standard in JPA 1.0 or 2.0, but has been
standardized in JDO since version 2.0 to support not only interfaces,
but also classes (abstract or concrete).  It looks like this:

public interface Person { String getName(); void String setName(String name); }
Person p = persistenceManager.newInstance(Person.class);
p.setName("Joe");
persistenceManager.makePersistent(p);

See section 12.6.6 of the JDO specification for more info.

-matthew

PS:  OpenJPA is descended from Kodo, one of the original JDO
implementations, which is where this nonstandard feature comes from.

RE: JPA 3.0

Posted by C N Davies <cn...@cndavies.com>.

Dynamic class generation isn't really so hard, we do it routinly in our
applications, just generate the java souce, compile it then instantiate it.
But 2 points seem to me to be the challenge for JPA.

1) The classes need to be enhanced  -  can be overcome by applying the same
enhancements that openjpac does 
2) We need the new class in persistence.xml or the wheels fall off. 

So I think the main task is to remove the requirement is to make this
requirement extensible at run time and ensure that this will cause JPA to
transform the schema and re-read it. The challenge is then what to do with
classes that pre-reshape were valid and post-reshape are not. So what do you
then do with dettached entities for example?
 
To me the fact that classes need to be enhanced is the single significant
limitation with the JPA spec. It is very limiting to future developments.

Chris



-----Original Message-----
From: Christopher Gardner [mailto:chris.r.gardner@gmail.com] 
Sent: Wednesday, 19 May 2010 12:32 AM
To: users@openjpa.apache.org
Subject: Re: JPA 3.0

My understanding is that Fluent NHibernate doesn't generate the entities.
 It's just a code equivalent to the hbm file.  I think someone else posted
the eclipse link ability to generate dynamic classes.

On Tue, May 18, 2010 at 10:17 AM, Kevin Sutter <kw...@gmail.com> wrote:

> Hi Jean-Baptiste,
> I'm with you on this aspect.  Producing the .java files, building them,
and
> then using them in a JVM seems to be a more logical means of accomplishing
> this task.
>
> But, since the poster was asking about the dynamic class approach like the
> Fluent Hibernate API, I thought it would still be an interesting exercise
> for someone.  Just not high on my priority list...  :-)
>
> Kevin
>
> On Sat, May 15, 2010 at 8:38 AM, Jean-Baptiste BRIAUD -- Novlog <
> j-b.briaud@novlog.com> wrote:
>
> > How do you generate classes dynamically (at runtime) in Java ???
> > Did you meant modifying the mapping at runtime for existing classes or
> did
> > you meant producing new classes at runtime and using it just after that
> and
> > still in the same JVM ?
> >
> > We are using OpenJPA 2.0 and are generating classes, but this is to
> > understand like generation time, before compile time before runtime.
> > So, we start producing .java text files that includes JPA annotation,
> then
> > compiling them, then using them by starting a new JVM.
> > To do so, we do not need any JPA dynamic modification not any kind of
JPA
> > introspection.
> > JPA introspection was not needed because the only modification I needed
> > coming from Hibernate was a way to change dynamically the eager/fetch
> > settings but that wonderful fetchplan feature did the job !
> >
> > On 12 mai 2010, at 17:06, Kevin Sutter wrote:
> >
> > > 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 <kw...@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 <kw...@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<go...@gmail.com>
>
<google-talk%3Amatthewadams12@gmail.com<google-talk%253Amatthewadams12@gmail
.com>
> >
> >
<google-talk%3Amatthewadams12@gmail.com<google-talk%253Amatthewadams12@gmail
.com>
>
<google-talk%253Amatthewadams12@gmail.com<google-talk%25253Amatthewadams12@g
mail.com>
> >
> > >
> > >> msn:matthew@matthewadams.me <ms...@matthewadams.me> <
> msn%3Amatthew@matthewadams.me <ms...@matthewadams.me>> <
> > msn%3Amatthew@matthewadams.me <ms...@matthewadams.me> <
> msn%253Amatthew@matthewadams.me <ms...@matthewadams.me>>>
> > >> http://matthewadams.me
> > >> http://www.linkedin.com/in/matthewadams
> > >>
> >
> >
>

Re: JPA 3.0

Posted by Christopher Gardner <ch...@gmail.com>.

My understanding is that Fluent NHibernate doesn't generate the entities.
 It's just a code equivalent to the hbm file.  I think someone else posted
the eclipse link ability to generate dynamic classes.

On Tue, May 18, 2010 at 10:17 AM, Kevin Sutter <kw...@gmail.com> wrote:

> Hi Jean-Baptiste,
> I'm with you on this aspect.  Producing the .java files, building them, and
> then using them in a JVM seems to be a more logical means of accomplishing
> this task.
>
> But, since the poster was asking about the dynamic class approach like the
> Fluent Hibernate API, I thought it would still be an interesting exercise
> for someone.  Just not high on my priority list...  :-)
>
> Kevin
>
> On Sat, May 15, 2010 at 8:38 AM, Jean-Baptiste BRIAUD -- Novlog <
> j-b.briaud@novlog.com> wrote:
>
> > How do you generate classes dynamically (at runtime) in Java ???
> > Did you meant modifying the mapping at runtime for existing classes or
> did
> > you meant producing new classes at runtime and using it just after that
> and
> > still in the same JVM ?
> >
> > We are using OpenJPA 2.0 and are generating classes, but this is to
> > understand like generation time, before compile time before runtime.
> > So, we start producing .java text files that includes JPA annotation,
> then
> > compiling them, then using them by starting a new JVM.
> > To do so, we do not need any JPA dynamic modification not any kind of JPA
> > introspection.
> > JPA introspection was not needed because the only modification I needed
> > coming from Hibernate was a way to change dynamically the eager/fetch
> > settings but that wonderful fetchplan feature did the job !
> >
> > On 12 mai 2010, at 17:06, Kevin Sutter wrote:
> >
> > > 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 <kw...@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 <kw...@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<go...@gmail.com>
> <go...@gmail.com>
> >
> > <go...@gmail.com>
> <go...@gmail.com>
> >
> > >
> > >> msn:matthew@matthewadams.me <ms...@matthewadams.me> <
> msn%3Amatthew@matthewadams.me <ms...@matthewadams.me>> <
> > msn%3Amatthew@matthewadams.me <ms...@matthewadams.me> <
> msn%253Amatthew@matthewadams.me <ms...@matthewadams.me>>>
> > >> http://matthewadams.me
> > >> http://www.linkedin.com/in/matthewadams
> > >>
> >
> >
>

Re: JPA 3.0

Posted by Kevin Sutter <kw...@gmail.com>.

Hi Jean-Baptiste,
I'm with you on this aspect.  Producing the .java files, building them, and
then using them in a JVM seems to be a more logical means of accomplishing
this task.

But, since the poster was asking about the dynamic class approach like the
Fluent Hibernate API, I thought it would still be an interesting exercise
for someone.  Just not high on my priority list...  :-)

Kevin

On Sat, May 15, 2010 at 8:38 AM, Jean-Baptiste BRIAUD -- Novlog <
j-b.briaud@novlog.com> wrote:

> How do you generate classes dynamically (at runtime) in Java ???
> Did you meant modifying the mapping at runtime for existing classes or did
> you meant producing new classes at runtime and using it just after that and
> still in the same JVM ?
>
> We are using OpenJPA 2.0 and are generating classes, but this is to
> understand like generation time, before compile time before runtime.
> So, we start producing .java text files that includes JPA annotation, then
> compiling them, then using them by starting a new JVM.
> To do so, we do not need any JPA dynamic modification not any kind of JPA
> introspection.
> JPA introspection was not needed because the only modification I needed
> coming from Hibernate was a way to change dynamically the eager/fetch
> settings but that wonderful fetchplan feature did the job !
>
> On 12 mai 2010, at 17:06, Kevin Sutter wrote:
>
> > 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 <kw...@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 <kw...@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 <kw...@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<go...@gmail.com>
> <go...@gmail.com>
> >
> >> msn:matthew@matthewadams.me <ms...@matthewadams.me> <
> msn%3Amatthew@matthewadams.me <ms...@matthewadams.me>>
> >> http://matthewadams.me
> >> http://www.linkedin.com/in/matthewadams
> >>
>
>

Re: JPA 3.0

Posted by Jean-Baptiste BRIAUD -- Novlog <j-...@novlog.com>.

How do you generate classes dynamically (at runtime) in Java ???
Did you meant modifying the mapping at runtime for existing classes or did you meant producing new classes at runtime and using it just after that and still in the same JVM ?

We are using OpenJPA 2.0 and are generating classes, but this is to understand like generation time, before compile time before runtime.
So, we start producing .java text files that includes JPA annotation, then compiling them, then using them by starting a new JVM.
To do so, we do not need any JPA dynamic modification not any kind of JPA introspection.
JPA introspection was not needed because the only modification I needed coming from Hibernate was a way to change dynamically the eager/fetch settings but that wonderful fetchplan feature did the job ! 

On 12 mai 2010, at 17:06, Kevin Sutter wrote:

> 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 <ma...@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 <kw...@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 <kw...@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 <kw...@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<go...@gmail.com>
>> msn:matthew@matthewadams.me <ms...@matthewadams.me>
>> http://matthewadams.me
>> http://www.linkedin.com/in/matthewadams
>>

Re: JPA 3.0

Posted by Kevin Sutter <kw...@gmail.com>.

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 <ma...@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 <kw...@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 <kw...@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 <kw...@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<go...@gmail.com>
> msn:matthew@matthewadams.me <ms...@matthewadams.me>
> http://matthewadams.me
> http://www.linkedin.com/in/matthewadams
>

Re: JPA 3.0

Posted by Matthew Adams <ma...@matthewadams.me>.

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 <kw...@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 <kw...@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 <kw...@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 <cn...@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
msn:matthew@matthewadams.me
http://matthewadams.me
http://www.linkedin.com/in/matthewadams

Re: JPA 3.0

Posted by Christopher Gardner <ch...@gmail.com>.

I don't know why it couldn't be a 3rd party item.

On Wed, May 12, 2010 at 10:10 AM, Kevin Sutter <kw...@gmail.com> wrote:

> :-)  Thanks, Laird.  This is the type of processing that I was envisioning
> with Christopher's post.  Neat, cool idea.  But, I'm still looking for the
> practicality of the proposal.  From what I am reading on the EclipseLink
> site, doing something similar in OpenJPA certainly looks doable.  I just
> don't see it rising on my priority list...  :-)  Any other takers?
>
> Kevin
>
> On Wed, May 12, 2010 at 8:39 AM, ljnelson <lj...@gmail.com> wrote:
>
> >
> > Interestingly, this just came up over in EclipseLink land:
> > http://wiki.eclipse.org/EclipseLink/Examples/JPA/Dynamic
> >
> > Best,
> > Laird
> >
> > On Wed, May 12, 2010 at 9:36 AM, Kevin Sutter [via OpenJPA] <
> > ml-node+5041111-372614786-210534@n2.nabble.com<ml...@n2.nabble.com>
> <ml...@n2.nabble.com>
> >
> > <ml...@n2.nabble.com>
> <ml...@n2.nabble.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 <
> > > [hidden email] <http://user/SendEmail.jtp?type=node&node=5041111&i=0>>
> > > 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 <[hidden email]<
> > http://user/SendEmail.jtp?type=node&node=5041111&i=1>>
> > > 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 <
> > > > > [hidden email] <
> http://user/SendEmail.jtp?type=node&node=5041111&i=2
> > >>
> > > 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 <[hidden email]<
> > http://user/SendEmail.jtp?type=node&node=5041111&i=3>>
> > >
> > > > > 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 <
> > > > > > > [hidden email]<
> > http://user/SendEmail.jtp?type=node&node=5041111&i=4>>
> > > 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 <[hidden
> email]<
> > http://user/SendEmail.jtp?type=node&node=5041111&i=5>
> > > > >
> > > > > > > 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]  [hidden email]<
> > http://user/SendEmail.jtp?type=node&node=5041111&i=6>
> > > > > > > > > [2]  https://issues.apache.org/jira/browse/OPENJPA
> > > > > > > > >
> > > > > > > > > On Tue, May 11, 2010 at 9:12 AM, C N Davies <[hidden
> email]<
> > http://user/SendEmail.jtp?type=node&node=5041111&i=7>>
> > >
> > > > > > 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
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > >
> > > ------------------------------
> > >  View message @
> > > http://openjpa.208410.n2.nabble.com/JPA-3-0-tp5036154p5041111.html
> > > To start a new topic under OpenJPA Users, email
> > > ml-node+208411-553807638-210534@n2.nabble.com<ml...@n2.nabble.com>
> <ml...@n2.nabble.com>
> >
> > <ml...@n2.nabble.com>
> <ml...@n2.nabble.com>
> >
> > >
> > > To unsubscribe from OpenJPA Users, click here< (link removed) =>.
> > >
> > >
> > >
> >
> > --
> > View this message in context:
> > http://openjpa.208410.n2.nabble.com/JPA-3-0-tp5036154p5041124.html
> > Sent from the OpenJPA Users mailing list archive at Nabble.com.
> >
>

Re: JPA 3.0

Posted by Kevin Sutter <kw...@gmail.com>.

:-)  Thanks, Laird.  This is the type of processing that I was envisioning
with Christopher's post.  Neat, cool idea.  But, I'm still looking for the
practicality of the proposal.  From what I am reading on the EclipseLink
site, doing something similar in OpenJPA certainly looks doable.  I just
don't see it rising on my priority list...  :-)  Any other takers?

Kevin

On Wed, May 12, 2010 at 8:39 AM, ljnelson <lj...@gmail.com> wrote:

>
> Interestingly, this just came up over in EclipseLink land:
> http://wiki.eclipse.org/EclipseLink/Examples/JPA/Dynamic
>
> Best,
> Laird
>
> On Wed, May 12, 2010 at 9:36 AM, Kevin Sutter [via OpenJPA] <
> ml-node+5041111-372614786-210534@n2.nabble.com<ml...@n2.nabble.com>
> <ml...@n2.nabble.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 <
> > [hidden email] <http://user/SendEmail.jtp?type=node&node=5041111&i=0>>
> > 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 <[hidden email]<
> http://user/SendEmail.jtp?type=node&node=5041111&i=1>>
> > 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 <
> > > > [hidden email] <http://user/SendEmail.jtp?type=node&node=5041111&i=2
> >>
> > 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 <[hidden email]<
> http://user/SendEmail.jtp?type=node&node=5041111&i=3>>
> >
> > > > 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 <
> > > > > > [hidden email]<
> http://user/SendEmail.jtp?type=node&node=5041111&i=4>>
> > 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 <[hidden email]<
> http://user/SendEmail.jtp?type=node&node=5041111&i=5>
> > > >
> > > > > > 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]  [hidden email]<
> http://user/SendEmail.jtp?type=node&node=5041111&i=6>
> > > > > > > > [2]  https://issues.apache.org/jira/browse/OPENJPA
> > > > > > > >
> > > > > > > > On Tue, May 11, 2010 at 9:12 AM, C N Davies <[hidden email]<
> http://user/SendEmail.jtp?type=node&node=5041111&i=7>>
> >
> > > > > 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
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> >
> > ------------------------------
> >  View message @
> > http://openjpa.208410.n2.nabble.com/JPA-3-0-tp5036154p5041111.html
> > To start a new topic under OpenJPA Users, email
> > ml-node+208411-553807638-210534@n2.nabble.com<ml...@n2.nabble.com>
> <ml...@n2.nabble.com>
> >
> > To unsubscribe from OpenJPA Users, click here< (link removed) =>.
> >
> >
> >
>
> --
> View this message in context:
> http://openjpa.208410.n2.nabble.com/JPA-3-0-tp5036154p5041124.html
> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>

Re: JPA 3.0

Posted by ljnelson <lj...@gmail.com>.

Interestingly, this just came up over in EclipseLink land:
http://wiki.eclipse.org/EclipseLink/Examples/JPA/Dynamic

Best,
Laird

On Wed, May 12, 2010 at 9:36 AM, Kevin Sutter [via OpenJPA] <
ml-node+5041111-372614786-210534@n2.nabble.com<ml...@n2.nabble.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 <
> [hidden email] <http://user/SendEmail.jtp?type=node&node=5041111&i=0>>
> 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 <[hidden email]<http://user/SendEmail.jtp?type=node&node=5041111&i=1>>
> 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 <
> > > [hidden email] <http://user/SendEmail.jtp?type=node&node=5041111&i=2>>
> 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 <[hidden email]<http://user/SendEmail.jtp?type=node&node=5041111&i=3>>
>
> > > 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 <
> > > > > [hidden email]<http://user/SendEmail.jtp?type=node&node=5041111&i=4>>
> 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 <[hidden email]<http://user/SendEmail.jtp?type=node&node=5041111&i=5>
> > >
> > > > > 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]  [hidden email]<http://user/SendEmail.jtp?type=node&node=5041111&i=6>
> > > > > > > [2]  https://issues.apache.org/jira/browse/OPENJPA
> > > > > > >
> > > > > > > On Tue, May 11, 2010 at 9:12 AM, C N Davies <[hidden email]<http://user/SendEmail.jtp?type=node&node=5041111&i=7>>
>
> > > > 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
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
>
> ------------------------------
>  View message @
> http://openjpa.208410.n2.nabble.com/JPA-3-0-tp5036154p5041111.html
> To start a new topic under OpenJPA Users, email
> ml-node+208411-553807638-210534@n2.nabble.com<ml...@n2.nabble.com>
> To unsubscribe from OpenJPA Users, click here< (link removed) =>.
>
>
>

-- 
View this message in context: http://openjpa.208410.n2.nabble.com/JPA-3-0-tp5036154p5041124.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.

Re: JPA 3.0

Posted by Kevin Sutter <kw...@gmail.com>.

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 <kw...@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 <kw...@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 <cn...@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
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: JPA 3.0

Posted by Christopher Gardner <ch...@gmail.com>.

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 <kw...@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 <kw...@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 <kw...@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 <cn...@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
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: JPA 3.0

Posted by Kevin Sutter <kw...@gmail.com>.

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 <kw...@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 <kw...@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 <cn...@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
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > >
> >
>

Re: JPA 3.0

Posted by Christopher Gardner <ch...@gmail.com>.

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 <kw...@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 <kw...@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 <cn...@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
> > > >
> > > >
> > > >
> > > >
> > >
> >
>

Re: JPA 3.0

Posted by Kevin Sutter <kw...@gmail.com>.

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 <kw...@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 <cn...@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
> > >
> > >
> > >
> > >
> >
>

Re: JPA 3.0

Posted by Christopher Gardner <ch...@gmail.com>.

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 <kw...@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 <cn...@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
> >
> >
> >
> >
>

Re: JPA 3.0

Posted by Kevin Sutter <kw...@gmail.com>.

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 <cn...@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
>
>
>
>