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

Groups > comp.lang.java.programmer > #14200

Re: Apache JDBC utils

Show all headers | View raw

On 5/1/2012 8:14 PM, Arved Sandstrom wrote:
> On 12-05-01 08:26 PM, Arne Vajhøj wrote:
>> On 4/30/2012 5:55 PM, markspace wrote:
>>> I'm making a small website as a personal project using only the JDBC
>>> interface. (No ORM, etc.) Well, I did the CRUD for exactly one bean and
>>> found it pretty tedious going. So I started looking around for something
>>> light-weight to help me out. I found the Apache commons dbutils project:
>>>
>>> <http://commons.apache.org/dbutils/>
>>
>>> And: is there a better, light-weight non-ORM package that you might
>>> recommend instead? Something a bit more complete.
>>
>> What are you actually gaining by not using a full blown ORM
>> (JPA, traditional Hibernate etc.)?
>
> Precisely so that you don't have a full-blown ORM with either a native
> API or JPA. I'll give you an example: I do integrations with lightweight
> ESBs [1], and sometimes I might have to write some simple JDBC in
> components and all I want are some Java Beans to represent the ResultSet
> rows. Just for packaging. Something like DBUtils could be handy (in fact
> I'm delighted that markspace reminded me of this handy API). I
> definitely don't want a full-blown JPA ORM in that environment.
>
> Like I said in another post, if you make an argument that a full-blown
> ORM is always preferable to a lightweight one, that's practically
> tantamount to saying that it never makes sense to use JDBC either.

If we are talking about "single row centric" then I would go for
either the heavy ORM to get functionality or plain JDBC to avoid
dependency (the last argument is more or less a SE only argument).
I would find it difficult to see a good argument for going with
the light ORM.

For "multi row centric" then I would go for plain JDBC as
ORM is not intended for that.

>> I doubt that you will save any code in your app.
>
> Likely not. That's not why you'd pick a rudimentary mapper.
>
>> I doubt that the less memory usage will be noticeable.
>
> Likely not. It's not why I'd make a decision.
>
>> It is not really a problem that the full blown ORM is hundreds
>> of thousands of lines of code, because maintenance is not
>> your responsibility.
>
> It's not, no. But that full-blown ORM with 500,000 lines of code (pretty
> close to what EclipseLink 2.2 has in its 'org' package [2]) is going to
> have quite a few more defects than an ORM with 5,000 lines of code
> (DBUtils has about 8,000 [2]).

That is obvious true, but I don't know if it is relevant.

If we follow the traditional rule of 1 bug per 1000 lines
of code, then we will see:

500 KLOC => 500 bugs
5 KLOC => 5 bugs

But there are two things to remember:
1) The same usage will only use a smaller portion of the large library.
2) This is when delivered first time. Bugs get fixed as they get found.
    The more the code is used the faster the bugs get found.

If we compare the 500 KLOC library with the 5 KLOC library then
doing what the small library can do may only use 25 or 50 KLOC of
the large library.

If that is the case and the larger library is used so much more than
the smaller library (and the functionality of the larger library
that can be done by the smaller library is most likely the
functionality most used) that there are 5 or 10 times less bugs
left per size, then there may actually be fewer bugs left.

Is this just number magic? I don't think so!

If you want a stable OS and a stable database would you go for
an exotic product with a small code base or a well known
product with a much larger code base?

> No particular aspersions on EclipseLink, but when one of those defects
> is hurting *your* project, even with access to source it's not
> straightforward to fix it, and it's not an overnighter to get the EL
> team to do so either. With as few lines of code are in DBUtils source,
 >
> *I* can fix it, and readily.

I would not want to fix it. I would want something where you can report
the bug to someone and let them fix it.

>> And some of the capabilities (like caching) could become
>> very handy in the future.
>
> The operative word being "could". Leaving aside the other management
> capabilities of the persistence context Level 1 cache, like uniqueness
> of identity within a PC, if you are constructing objects with a simple
> mapper like DBUtils you *have* a cache. Your objects are in memory;
> you're not hitting the DB every time you need them.

That is not really level 1 cache.

> As for JPA Level 2, well, that's a decision best approached carefully
> and not made available by default. I surely don't think you need to go
> with JPA just in case you might need Level 2 cache at some point.

If it was just that: no. But there are other features that also could
become useful.

Arne

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

Thread

Apache JDBC utils markspace <-@.> - 2012-04-30 14:55 -0700
  Re: Apache JDBC utils Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-04-30 20:56 -0300
    Re: Apache JDBC utils markspace <-@.> - 2012-04-30 17:50 -0700
  Re: Apache JDBC utils Lew <lewbloch@gmail.com> - 2012-04-30 18:03 -0700
    Re: Apache JDBC utils markspace <-@.> - 2012-04-30 19:27 -0700
      Re: Apache JDBC utils Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-05-01 10:29 -0300
        Re: Apache JDBC utils markspace <-@.> - 2012-05-01 08:57 -0700
          Re: Apache JDBC utils Lew <lewbloch@gmail.com> - 2012-05-02 11:16 -0700
            Re: Apache JDBC utils markspace <-@.> - 2012-05-03 07:51 -0700
    Re: Apache JDBC utils Arne Vajhøj <arne@vajhoej.dk> - 2012-05-01 19:22 -0400
  Re: Apache JDBC utils Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-05-01 10:32 -0700
    Re: Apache JDBC utils markspace <-@.> - 2012-05-01 11:22 -0700
      Re: Apache JDBC utils Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-05-01 15:26 -0700
        Re: Apache JDBC utils Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-05-01 19:44 -0300
  Re: Apache JDBC utils Arne Vajhøj <arne@vajhoej.dk> - 2012-05-01 19:26 -0400
    Re: Apache JDBC utils Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-05-01 21:14 -0300
      Re: Apache JDBC utils Leif Roar Moldskred <leifm@dimnakorr.com> - 2012-05-01 22:22 -0500
        Re: Apache JDBC utils Arne Vajhøj <arne@vajhoej.dk> - 2012-05-03 13:52 -0400
      Re: Apache JDBC utils Arne Vajhøj <arne@vajhoej.dk> - 2012-05-03 13:51 -0400
        Re: Apache JDBC utils Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-05-03 17:11 -0300
          Re: Apache JDBC utils Arne Vajhøj <arne@vajhoej.dk> - 2012-05-03 16:58 -0400
            Re: Apache JDBC utils Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-05-03 18:25 -0300
              Re: Apache JDBC utils Arne Vajhøj <arne@vajhoej.dk> - 2012-05-03 19:55 -0400
    Re: Apache JDBC utils Leif Roar Moldskred <leifm@dimnakorr.com> - 2012-05-01 22:08 -0500
      Re: Apache JDBC utils Arne Vajhøj <arne@vajhoej.dk> - 2012-05-03 13:55 -0400
        Re: Apache JDBC utils Leif Roar Moldskred <leifm@dimnakorr.com> - 2012-05-03 13:44 -0500
          Re: Apache JDBC utils Arne Vajhøj <arne@vajhoej.dk> - 2012-05-03 15:06 -0400
  Re: Apache JDBC utils "John B. Matthews" <nospam@nospam.invalid> - 2012-05-01 23:37 -0400
    Re: Apache JDBC utils Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-05-02 07:37 -0300
      Re: Apache JDBC utils "John B. Matthews" <nospam@nospam.invalid> - 2012-05-02 18:51 -0400
  Re: Apache JDBC utils Jan Burse <janburse@fastmail.fm> - 2012-05-02 12:22 +0200
    Re: Apache JDBC utils markspace <-@.> - 2012-05-02 08:29 -0700
      Re: Apache JDBC utils Jan Burse <janburse@fastmail.fm> - 2012-05-02 22:02 +0200
        Re: Apache JDBC utils Lew <lewbloch@gmail.com> - 2012-05-02 14:22 -0700
          Re: Apache JDBC utils Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-05-02 18:53 -0300
          Re: Apache JDBC utils Jan Burse <janburse@fastmail.fm> - 2012-05-03 00:03 +0200
            Re: Apache JDBC utils Jan Burse <janburse@fastmail.fm> - 2012-05-03 00:14 +0200
            Re: Apache JDBC utils Jan Burse <janburse@fastmail.fm> - 2012-05-03 00:27 +0200
              Re: Apache JDBC utils Arne Vajhøj <arne@vajhoej.dk> - 2012-05-03 14:03 -0400
            Re: Apache JDBC utils Arne Vajhøj <arne@vajhoej.dk> - 2012-05-02 18:58 -0400
            Re: Apache JDBC utils Lew <lewbloch@gmail.com> - 2012-05-02 16:18 -0700
          Re: Apache JDBC utils Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-05-02 15:25 -0700
            Re: Apache JDBC utils Jan Burse <janburse@fastmail.fm> - 2012-05-03 00:59 +0200
              Re: Apache JDBC utils Arne Vajhøj <arne@vajhoej.dk> - 2012-05-03 14:05 -0400
            Re: Apache JDBC utils Lew <lewbloch@gmail.com> - 2012-05-02 16:24 -0700
              Re: Apache JDBC utils Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-05-02 16:35 -0700
              Re: Apache JDBC utils Jan Burse <janburse@fastmail.fm> - 2012-05-03 01:46 +0200
              Re: Apache JDBC utils Jan Burse <janburse@fastmail.fm> - 2012-05-03 01:49 +0200

csiph-web