Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.help > #969

Re: Doing JDBC code in a less unwieldy way?

Show all headers | View raw

On 11-08-21 10:54 AM, Ricardo Palomares Martínez wrote:
> El 20/08/11 15:59, Arved Sandstrom escribió:
>> "Way more basic than Hibernate et al."? Are you kidding?
> 
> 
> Did I look like kidding?
> 
> 
>> I just looked
>> at the EoDSQL tutorial, and it definitely appears that the basic case
>> for EoDSQL is somewhat more complicated than it is for JPA.
> 
> 
> I was not talking specifically about JPA, and honestly I was thinking
> more of Hibernate. I must also say that I compared Hibernate & EoD
> (even before that EoDSQL itself) Hibernate was way more complex and
> overkill for small needs.

OK, fair enough, but what sets the bar these days for Java persistence
is JPA, especially JPA 2. If you wish to promote anything else - use of
straight JDBC, or an SQL mapper like MyBatis or EoDSQL - then the thing
to compare to is not Hibernate or EclipseLink (or OpenJPA to some
extent) native APIs, but the JPA API provided by Hibernate or
EclipseLink or OpenJPA JPA.

> Regarding the example, EodSQL doesn't use JQL, has only six
> annotations, six interfaces and three classes in the general package
> most users will only need. Could you give a rough estimate of how that
> does compare to JPA?

SQL mappers like EoDSQL or MyBatis don't use JPQL, no, but they devote a
lot of effort - and so do their users - to mapping SQL to Java objects.
That JPA has standard maps called "entities" that in the default case
correspond to a DB table doesn't obscure the fact that all these
libraries are ultimately doing mapping. And JPA provides for a standard
way of producing non-entity Java objects from queries also: constructor
expressions.

Regarding the example, assuming fairly basic tables, you'd have as many
JPA entity classes as there are tables, and the persistence.xml
configuration file, which as I stated before might be 15-20 lines for
this example. Depending on types of table relationships, ID generation,
use of named queries, and how you manage persistent objects
(application-managed or container-managed) there could be anywhere from
half a dozen to a dozen different annotations in use for this case. JPA
interfaces/classes in use might be half a dozen to a dozen; it's
difficult to say more exactly.

[ SNIP ]

>> Pretty even on the basic query infrastructure...until you start looking
>> at everything else that you get with JPA. For example, if I have
>> retrieved a Person entity with a JPA query (or "find"), I can get a list
>> of related entities by using getter methods. The JPA provider, since it
>> knows about relationships through entity class annotations, takes care
>> of all the SQL under the hood. How does EoDSQL deal with that?
> 
> It doesn't intend to do that (so you don't need either to learn how
> JPA does it).

Right...but at some point the user may well want to do those things.
> 
>> The tutorial also shows DAI updates and inserts. Well, for JPA, assuming
>> container-management in a Java EE environment, an insert looks like
>>
>> em.persist(person);
>>
>> and an update looks like
>>
>> person.modify(data);
> 
> 
> With EoSQL DAIs, you may have equally simple methods, based on a DAI.
> The DAI can be defined inside the POJO, so the POJO carries the DB
> access logic. Creating a DAI for an User object then is like this:
> 
> ...
>   User u = new User();
>   User.UserDAI ud = QueryTool.getQuery(ds, User.UserDAI.class);
> ...
> 
> and you're ready to insert, query, update or delete users.

Except with an SQL mapper you have to write all the SQL.

>> You can't beat the simplicity of the JPA insert. As for the JPA
>> update...well, there ain't one. You don't need to tell the persistence
>> provider to update, it knows when to do it because you changed the
>> managed object.
> 
> It is a matter of taste, and I bet you can prove me why I'm wrong, but
> I always felt that I wanted to be the one deciding when to update the
> DB, without having to detach the entity myself.

No, I won't prove you wrong. It's not a matter of taste, leastways it
ought not to be. You choose JPA partly because you're not interested in
doing all the low-level book-keeping yourself.

And with JPA you do have choice as to when and if an entity gets
updated, say. It's up to you as to whether any given entity is managed -
if it's not the ORM doesn't know about it.

>> Don't get me wrong, I'm not totally dumping on what the basic mappers
>> do.
> 
> 
> If you read again my previous post, you will realize that I'm not
> discouraging advanced ORMs either (in fact, I didn't even mention
> JPA). I was just presenting a different option that is simpler to
> learn (and it is, believe me) than what had been already mentioned. I
> said:
> 
>> It is way more basic than Hibernate et al. (and thus easier to learn),

Hibernate native API, yes.

> so, if any, I was putting the emphasis in that it is more basic,
> rather than it eaiser. I presume the OP can decide himself if, at
> their current status, something simple and less powerful can pay off
> to later switch to a more standard and extensible solution.

He'd still be making an argument for a third-party library, and I
believe that for his use case any of the options would involve
comparable effort. From the sounds of it his management wouldn't like
any of them.

[ SNIP ]

>> My recommendation for anyone wanting to speak intelligently about Java
>> persistence is, use all of the possibilities and use them enough to get
>> the quirks and the problems and the advantages. Take a real world
>> problem with 50 or 100 or 500 tables, (...) Try that solve that with straight JDBC, then with an
>> SQL mapper like EoDSQL or MyBatis for Java, then with a JPA persistence
>> provider like EclipseLink.
> 
> 
> Yes, but don't forget is that the *real world* problem we're talking
> about _does_ have "...about a half dozen tables in an Oracle db...".
> There is no more real example than the OP has described as *his* problem.

And my contention is that even for his example JPA will not be more
complex or take longer to do than EoDSQL.

AHS

Back to comp.lang.java.help | Previous | Next — Previous in thread | Find similar

Thread

Doing JDBC code in a less unwieldy way? Steve <tinker123@gmail.com> - 2011-08-18 11:26 -0400
  Re: Doing JDBC code in a less unwieldy way? markspace <-@.> - 2011-08-18 08:57 -0700
    Re: Doing JDBC code in a less unwieldy way? Lew <lewbloch@gmail.com> - 2011-08-18 11:26 -0700
  Re: Doing JDBC code in a less unwieldy way? Roedy Green <see_website@mindprod.com.invalid> - 2011-08-19 02:00 -0700
    Re: Doing JDBC code in a less unwieldy way? Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-08-19 08:59 -0300
      Re: Doing JDBC code in a less unwieldy way? Lew <lewbloch@gmail.com> - 2011-08-19 07:57 -0700
      Re: Doing JDBC code in a less unwieldy way? Steve <tinker123@gmail.com> - 2011-08-19 19:50 -0400
        Re: Doing JDBC code in a less unwieldy way? Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-08-19 21:26 -0300
          Re: Doing JDBC code in a less unwieldy way? Lew <lewbloch@gmail.com> - 2011-08-19 20:20 -0700
      Re: Doing JDBC code in a less unwieldy way? Roedy Green <see_website@mindprod.com.invalid> - 2011-08-20 17:19 -0700
        Re: Doing JDBC code in a less unwieldy way? Lew <lewbloch@gmail.com> - 2011-08-20 18:53 -0700
        Re: Doing JDBC code in a less unwieldy way? Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-08-21 10:32 -0300
  Re: Doing JDBC code in a less unwieldy way? Ricardo Palomares Martínez <rpm.PUBLI@iespana.es> - 2011-08-20 13:07 +0200
    Re: Doing JDBC code in a less unwieldy way? Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-08-20 10:59 -0300
      Re: Doing JDBC code in a less unwieldy way? Lew <lewbloch@gmail.com> - 2011-08-20 10:02 -0700
        Re: Doing JDBC code in a less unwieldy way? Ricardo Palomares Martínez <rpm.PUBLI@iespana.es> - 2011-08-21 16:03 +0200
      Re: Doing JDBC code in a less unwieldy way? Ricardo Palomares Martínez <rpm.PUBLI@iespana.es> - 2011-08-21 15:54 +0200
        Re: Doing JDBC code in a less unwieldy way? Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-08-22 18:56 -0300

csiph-web