You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@openjpa.apache.org by Daniel Toffetti <dt...@yahoo.com.ar> on 2010/06/26 02:46:18 UTC
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.
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.