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

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

Re: Doing JDBC code in a less unwieldy way?

Show all headers | View raw

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.

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?


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


Actually, it only follows the JDBC 4.0 EoD specification, that also
describes first the use of public members and then Beans. It is just
that the EoDSQL author minded to state that using reflection involves
doing more things than accessing a public member.


> 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).




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


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


> 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),

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.


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


DataSet in EoDSQL also manages result sets implementing java.util.List
interface.


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



--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

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