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

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

Re: Apache JDBC utils

Show all headers | View raw

On 5/3/2012 4:11 PM, Arved Sandstrom wrote:
> On 12-05-03 02:51 PM, Arne Vajhøj wrote:
>> 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 think I'd analyze it probably the same way. Usually.
>
> However, the situation I am describing here - it's one example, there
> are others - is one where I don't want JPA or native ORM units-of-work
> or anything barely above raw JDBC. It's simply the case that from time
> to time I might want to package a ResultSet row as an object, with zero
> special meaning. That's all I'm saying.
>
> It's not like I often have this requirement. 90+ percent of the tiem
> it's JPA for me, almost all of the rest is plain JDBC. Using a simple OR
> mapper like DBUtils would be very occasional.

Hard to argue against anything being a good choice "very occasional".

Occasionally the requirements are slightly different than the usual.

>>>> 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?
>
> The LOC count isn't one that I'd use to make the decision, Arne.
> Although I'd certainly read the bug database to find out what could hurt.
>
> You mentioned maintenance, not me, and I know from bitter experience
> that ORM problems are *my* problems.
>
> But I'll reiterate that if I went with a small, very rudimentary mapper
> that it would be special case and a situation where a full-blown ORM
> would be massive overkill.

Yes.

And I am sure that such cases do exist.

I am just trying to argue that in most cases a big
jar files is not a problem in itself.

>>> 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.
>
> You have no real choice with a large ORM anyway. You report it, and if
> you're lucky a few minor versions down the pipe and a few months later
> you see a fix.

This is the industry way.

>>>> 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.
>
> What do you consider to be a cache? A cache means that you've got your
> stuff in a storage area that's faster to access than the original
> location. Usually memory. If I get my stuff through JDBC, and access
> data afterwards off the ResultSet, that's a cache. If I convert that
> ResultSet to a collection of objects, and access data in that collection
> afterwards, that's a cache.
>
> Insofar as this level of caching is similar to a persistence context,
> which is referred to as Level 1 in JPA, I have no problems thinking of
> it as Level 1 equivalent.

I would define an ORM cache as a cache in the ORM code not a cache
in my code.

Otherwise any ORM would have a cache since the O will be in memory.

>>> 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.
>
> Hopefully you know what you need early on, considering as how you did
> good requirements analysis. In which case you're using JPA because you
> already know you need it.

I don't think I have ever seen requirements that actually covered
all requirements for the actual lifetime of the application.

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