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

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

Re: Doing JDBC code in a less unwieldy way?

Show all headers | View raw

Arved Sandstrom wrote:
> Ricardo Palomares Martínez wrote:
>> Steve escribió:
>>> I'm renovating an old servlet application.   It has some complex and
>>> poorly thought out database functions for inserting and updating a
>>> number of tables.
>>> (...)
>>> The place where I work isn't ready to go to a framework and something
>>> like a hibernate yet.
> > 
> > When Java 6 was being developed, there was a feature to add a simple
> > mapping to JDBC out of the box. Sadly, it was removed just before Java
> > 6 was launched.

Excuse me?  There was a specification included, abeit in the contemporaneous Java EE, and they called it "JPA", and three major versions of it exist, and it works fine with Java SE 5 and 6.

WTF?

>> A guy decided to implement it and produced EoDSQL:

"A guy"?

>> http://java.net/projects/eodsql/
>> 
>> It is way more basic than Hibernate et al. (and thus easier to learn),
>> but still helpul to centralize all the DB code. You may want to give
>> it a try.
> 
> "Way more basic than Hibernate et al."? Are you 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. Since that's
> the _only_ case for EoDSQL (it can't compete with JPA on other
> functionality, because it doesn't have it), what's the point?
> 
> In the tutorial I see Data Objects (DOs). These are entity classes in
> JPA. The tutorial seems to lean towards making the DO member fields
> public, and the supposed reason is "a little bit of a runtime
> performance penalty". That's pretty weak. I think the real reason for
> showing the DOs with public member fields is so that the accessors can
> be omitted and create the illusion of compactness...which is even more weak.
> 
> The EoDSQL tutorial also introduces Data Access Interfaces (DAIs). Let's
> look at what is demonstrated here. First, queries. JPA already gives you
> the "find by ID" query out of the box, as a "find". Other SELECTs in JPA
> are also written out, just as with EoDSQL, and may be included *with*
> the target entity class as named queries, available by name from elsewhere.
> 
> 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?
> 
> 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);
> 
> 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.
> 
> Finally, the EoDSQL tutorial discusses the Query Tool. Part of what this
> class does is handled by the JPA persistence.xml, part by how a coder
> would obtain EntityManagers in their Java SE/EE environment. The EoDSQL
> Query Tool doesn't simplify anything in this respect: the basics of
> setting JDBC properties _somewhere_ and possibly using DataSources have
> to be done in _any_ approach.
> 
> The QueryTool also has adhoc SQL generation capabilities. That's fine;
> so does the JPA EntityManager interface through various query creation
> possibilities.
> 
> Don't get me wrong, I'm not totally dumping on what the basic mappers
> do. There are a lot of good reasons for having data access layers -
> quite frankly, even with JPA - and a central feature of DALs is that
> they consolidate the persistence code. So all your SQL, if you're using
> straight JDBC, ends up in the same place, and is easier to manage. The
> EoDSQL DAIs basically support that concept.
> 
> But so does JPA - queries can be (and whenever possible, should be)
> defined as named queries and kept in one place. Other data access layer
> principles can be easily introduced also.
> 
> It's also cool that the next logical step is considered by EoDSQL:
> result set mapping to Java objects. EoDSQL does some of that. But the
> point is, so does JPA. But if result sets are needed JPA does that too.
> 
> My question is, why would you do comparable amounts of work for both JPA
> and EoDSQL to handle a simple case like the OP has, when you know that
> when you're done there is no real extra functionality provided by
> EoDSQL, but major extra capability in JPA?
> 
> The only thing I can figure is that some teams out there - EoDSQL,
> iBatis/MyBatis, Empire-db etc - somehow think that the _management_ of
> persistent objects is heavyweight and complicated and to be avoided. And
> they then call themselves "lightweight" for no real justification that I
> can discern. "Lightweight" how exactly? In this day and age when even
> Spring calls itself "lightweight" it's a useless term. I don't get why
> the management of persistent objects is something to avoid.
> 
> 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, and hundreds of FK relationships
> and other constraints (as in, would you like to define a VARCHAR column
> as mapping to a Java enum?), then consider a typical web app scenario
> where the persistence transaction may have to exist over multiple HTTP
> requests, etc etc. 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.
> 
> I'll add, don't think that life becomes rosy with JPA. It doesn't. This
> is actually not a reflection on only JPA, it's a consequence of the fact
> that correct, efficient, large-scale coding of DB access logic is hard.
> Period.

+1

JPA is definitely the answer to ORM (object-relational mapping).  It is not the answer for all tasks handled by JDBC, but that's another rant.

But remember - the purpose of JPA is to support object operations, not relational operations.  There's a fundamental difference between the two world views.  One of the simplicities of JPA is that you can say "SELECT Order o WHERE o.customer = someCustomer" and not have to explicitly refer to the keys.

-- 
Lew
It is wrong to ever split an infinitive.

Back to comp.lang.java.help | Previous | Next — Previous in thread | Next 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