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

Groups > comp.lang.java.programmer > #14057 > unrolled thread

Apache JDBC utils

Back to article view | Back to comp.lang.java.programmer

Contents

  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

Page 1 of 3  [1] 2 3  Next page →

#14057 — Apache JDBC utils

Hey all,

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

This makes reading a bean much much easier.  It does most of the column 
to property matching for you and will read an entity into a bean with 
only a few lines of code.  Here's a (mostly) complete example from my 
little project:

    public UserBean getByUsername( String name ) {
       QueryRunner run = new QueryRunner( dataSource );
       BeanHandler<UserBean> handler = new BeanHandler( UserBean.class );
       UserBean user = null;
       try {
        user=run.query( sqlStatements.getProperty( LOGIN_BY_USERNAME ),
                  handler, name );
       } catch( SQLException ex ) {
          Logger.getLogger( UserDataMapper.class.getName() ).
                  log( Level.SEVERE, null, ex );
       }
       return user;
    }


That's a lot less 'faffing about' reading the fields of a ResultSet into 
a simple bean, and a much higher signal-to-noise ratio imo.

The problem is, this only works for reading a simple entity.  There 
doesn't seem to be any equivalent for update, create, or delete.

So my question is: does any have experience with dbutils and see's 
something I'm missing?  Would you take a look at the docs even if you 
don't have experience with dbutils?

And: is there a better, light-weight non-ORM package that you might 
recommend instead?  Something a bit more complete.

Anyway, I'm in the middle of adding basic update and create, and it's 
actually going well.  (It'd be going better if I weren't some clumsy 
with SQL syntax.)  But I thought I'd ask to see what other ideas the 
folks here on this news group might have.

Thanks!

[toc] | [next] | [standalone]

#14060

On 12-04-30 06:55 PM, markspace wrote:
> Hey all,
> 
> 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/>
> 
> This makes reading a bean much much easier.  It does most of the column
> to property matching for you and will read an entity into a bean with
> only a few lines of code.  Here's a (mostly) complete example from my
> little project:
> 
>    public UserBean getByUsername( String name ) {
>       QueryRunner run = new QueryRunner( dataSource );
>       BeanHandler<UserBean> handler = new BeanHandler( UserBean.class );
>       UserBean user = null;
>       try {
>        user=run.query( sqlStatements.getProperty( LOGIN_BY_USERNAME ),
>                  handler, name );
>       } catch( SQLException ex ) {
>          Logger.getLogger( UserDataMapper.class.getName() ).
>                  log( Level.SEVERE, null, ex );
>       }
>       return user;
>    }
> 
> 
> That's a lot less 'faffing about' reading the fields of a ResultSet into
> a simple bean, and a much higher signal-to-noise ratio imo.
> 
> The problem is, this only works for reading a simple entity.  There
> doesn't seem to be any equivalent for update, create, or delete.
> 
> So my question is: does any have experience with dbutils and see's
> something I'm missing?  Would you take a look at the docs even if you
> don't have experience with dbutils?

I haven't used DBUtils myself, but right in
http://commons.apache.org/dbutils/examples.html I can see examples of
INSERTs and UPDATEs (so presumably DELETEs are fine too :_))

> And: is there a better, light-weight non-ORM package that you might
> recommend instead?  Something a bit more complete.

Check out http://www.mybatis.org/java.html.

> Anyway, I'm in the middle of adding basic update and create, and it's
> actually going well.  (It'd be going better if I weren't some clumsy
> with SQL syntax.)  But I thought I'd ask to see what other ideas the
> folks here on this news group might have.
> 
> Thanks!
> 
AHS

-- 
A fly was very close to being called a "land," cause that's what they do
half the time.
-- Mitch Hedberg

[toc] | [prev] | [next] | [standalone]

#14061

On 4/30/2012 4:56 PM, Arved Sandstrom wrote:

> I haven't used DBUtils myself, but right in
> http://commons.apache.org/dbutils/examples.html I can see examples of
> INSERTs and UPDATEs (so presumably DELETEs are fine too :_))


I looked at that but didn't strongly consider it, I guess.  It seems 
(still) a bit more tedious that I'd like.  For example, to update some 
bean, you have to call "get" on each one of its properties.  So, while 
the docs show this:

     // Now it's time to rise to the occation...
     int updates = run.update( "UPDATE Person SET height=? WHERE name=?",
                               2.05, "John Doe" );

A slightly more realistic example would be something like this:

     // Now it's time to rise to the occation...
     int updates = run.update( "UPDATE Person SET height=?, weight=?, 
id=?, foo=?, bar=?, argleBarble=? WHERE name=?",
       aBean.getHeight(), aBean.getWeight(), aBean.getId(), 
aBean.getFoo(), aBean.getBar(), aBean.getArgleBarble(), aBean.getName() );

Which is just a tad messier than I want:

   SimpleSql.updateBean( dataSource, aBean );

Although I can see advantages with their method.  Theirs is a lot more 
flexible, and perhaps I'm being too narrow minded in how I expect a bean 
to be used in practice.

Or possibly I'm having too much fun faffing about with the reflection 
API. ;-)

>
>> And: is there a better, light-weight non-ORM package that you might
>> recommend instead?  Something a bit more complete.
>
> Check out http://www.mybatis.org/java.html.

Thanks for that, I'll check it out.

[toc] | [prev] | [next] | [standalone]

#14063

On Monday, April 30, 2012 2:55:51 PM UTC-7, markspace wrote:
> Hey all,
> 
> 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 

That's funny. You say, "No ORM", then immediately describe the ORM library you're using.

> and found it pretty tedious going.  So I started looking around for 

Yes, it is. That's why ORM frameworks are popular.

I've done this exercise myself, repeatedly. I've written a handful of project-specific ORM layers, used a number of off-the-shelf products, and done direct comparisons between JPA and raw JDBC idioms (with custom ORM) with two or more idiomatic approach each for the JPA and JDBC styles.

The idiom that won for me was non-monolithic JPA (as opposed to the monolithic idiom I've seen in most shops and was the root of their complaints about JPA).

It is very light weight, for how I use the term "light weight".

How do you mean the term, precisely?

> something light-weight [sic] to help me out.  I found the Apache commons 
> dbutils project:
> 
> <http://commons.apache.org/dbutils/>
> 
> This makes reading a bean much much easier.  It does most of the column 
> to property matching for you and will read an entity into a bean with 
> only a few lines of code.  Here's a (mostly) complete example from my 
> little project:
> 
>     public UserBean getByUsername( String name ) {
>        QueryRunner run = new QueryRunner( dataSource );
>        BeanHandler<UserBean> handler = new BeanHandler( UserBean.class );
>        UserBean user = null;
>        try {
>         user=run.query( sqlStatements.getProperty( LOGIN_BY_USERNAME ),
>                   handler, name );
>        } catch( SQLException ex ) {
>           Logger.getLogger( UserDataMapper.class.getName() ).
>                   log( Level.SEVERE, null, ex );
>        }
>        return user;
>     }
> 
> 
> That's a lot less 'faffing about' reading the fields of a ResultSet into 
> a simple bean, and a much higher signal-to-noise ratio imo.

Yes, that's the advantage of ORMs generally.

I prefer EclipseLink and OpenJPA, myself. They go so far as to abstract away even that pseudo-SQL, for the common case. You write some annotations and Bob's your uncle.

> The problem is, this only works for reading a simple entity.  There 
> doesn't seem to be any equivalent for update, create, or delete.
> 
> So my question is: does any have experience with dbutils and see's 
> something I'm missing?  Would you take a look at the docs even if you 
> don't have experience with dbutils?
> 
> And: is there a better, light-weight non-ORM package that you might 
> recommend instead?  Something a bit more complete.

How is the one you're using not ORM?

It maps between objects and relational entities. Object-to-relational mapping. Q.E.D.

> Anyway, I'm in the middle of adding basic update and create, and it's 
> actually going well.  (It'd be going better if I weren't some clumsy 
> with SQL syntax.)  But I thought I'd ask to see what other ideas the 
> folks here on this news group might have.

JPA.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#14068

On 4/30/2012 6:03 PM, Lew wrote:
>
> That's funny. You say, "No ORM", then immediately describe the ORM
> library you're using.
...
 > How is the one you're using not ORM?


Well, I'll point out the main landing page for the project specifically 
says that dbutils is not an ORM.

"DbUtils is not:

     An Object/Relational bridge - there are plenty of good O/R tools 
already. DbUtils is for developers looking to use JDBC without all the 
mundane pieces."

<http://commons.apache.org/dbutils/>

If the authors of the projects say it's not ORM, I'll choose to believe 
them.


> The idiom that won for me was non-monolithic JPA (as opposed to the
> monolithic idiom I've seen in most shops and was the root of their
> complaints about JPA).


Could you describe what you mean by "non-monolithic" vs "monolithic?"  I 
don't think I've heard those terms before and I'd be interested to see 
what you are referring too.

As for "I've done this exercise myself, repeatedly" yeah I seem to be 
going down the same road.  Building small prototypes to see how the 
result actually functions.  In general I think doing is the best way to 
learn, so I don't mind doing some extra work in order to get some learnin'.


> It is very light weight, for how I use the term "light weight".
>
> How do you mean the term, precisely?


I think I mean relatively speaking.  Something is lighter weight in 
comparison to certain alternates.  Lighter weight in terms of options, 
configuration required or configuration options, lighter weight in terms 
of number features needed to learn, lighter weight in terms of API calls 
needed to be conversant with before one can be productive.


> I prefer EclipseLink and OpenJPA, myself. They go so far as to
> abstract away even that pseudo-SQL, for the common case. You write
> some annotations and Bob's your uncle.


I'm somewhat conversant with JPA 2.0.  I'm just looking at alternatives 
for a comparison.  What, if any, advantages do other APIs provide?  So 
far my personal jury is still out.  Although I can see a customer for 
example specify specifying something other than JPA for their own 
reasons, and it might not (as in very probably not) be my place to 
second-guess their business decision.  That I think would be the main 
reason, imo, to not use a full JPA solution.

[toc] | [prev] | [next] | [standalone]

#14072

On 12-04-30 11:27 PM, markspace wrote:
> On 4/30/2012 6:03 PM, Lew wrote:
>>
>> That's funny. You say, "No ORM", then immediately describe the ORM
>> library you're using.
> ...
>> How is the one you're using not ORM?
> 
> 
> Well, I'll point out the main landing page for the project specifically
> says that dbutils is not an ORM.
> 
> "DbUtils is not:
> 
>     An Object/Relational bridge - there are plenty of good O/R tools
> already. DbUtils is for developers looking to use JDBC without all the
> mundane pieces."
> 
> <http://commons.apache.org/dbutils/>
> 
> If the authors of the projects say it's not ORM, I'll choose to believe
> them.

To an extent I'm happy to go with what authors say also. More precisely
DBUtils *is* an ORM - just look at the available ResultSetHandler
implementations like BeanListHandler - but it sure isn't an ORM like
Hibernate JPA or EclipseLink are.

I prefer to differentiate between basic OR mappers like DBUtils that do
low-level first-tier stuff, and full-blown JPA implementations. They are
all ORMs but there are massive differences in capability.

>> The idiom that won for me was non-monolithic JPA (as opposed to the
>> monolithic idiom I've seen in most shops and was the root of their
>> complaints about JPA).
> 
> 
> Could you describe what you mean by "non-monolithic" vs "monolithic?"  I
> don't think I've heard those terms before and I'd be interested to see
> what you are referring too.

I am curious myself. :-)

> As for "I've done this exercise myself, repeatedly" yeah I seem to be
> going down the same road.  Building small prototypes to see how the
> result actually functions.  In general I think doing is the best way to
> learn, so I don't mind doing some extra work in order to get some learnin'.
> 
>> It is very light weight, for how I use the term "light weight".
>>
>> How do you mean the term, precisely?
> 
> I think I mean relatively speaking.  Something is lighter weight in
> comparison to certain alternates.  Lighter weight in terms of options,
> configuration required or configuration options, lighter weight in terms
> of number features needed to learn, lighter weight in terms of API calls
> needed to be conversant with before one can be productive.

I tend to agree. For example, DBUtils allows one to create a set of
domain classes that can be rich (see other threads :-)) so long as they
are Java Beans, and they are unaware of DBUtils. It's extremely simple
to populate one or a list of these beans with ResultSet data.

But as far as I know there is no DBUtils transactions support. There is
certainly no object management. This makes it pretty lightweight to me.

With JPA you can go easy on the annotations, using ORM XML, and
therefore also have domain classes that are JPA unaware, but the
distinction remains that in JPA you had to configure the mappings
somewhere, but in DBUtils the mapping remains conceptual. Less artifacts
with DBUtils, seriously less capability, no object management - I know
what's lighter-weight in this picture.

>> I prefer EclipseLink and OpenJPA, myself. They go so far as to
>> abstract away even that pseudo-SQL, for the common case. You write
>> some annotations and Bob's your uncle.
> 
> I'm somewhat conversant with JPA 2.0.  I'm just looking at alternatives
> for a comparison.  What, if any, advantages do other APIs provide?  So
> far my personal jury is still out.  Although I can see a customer for
> example specify specifying something other than JPA for their own
> reasons, and it might not (as in very probably not) be my place to
> second-guess their business decision.  That I think would be the main
> reason, imo, to not use a full JPA solution.
> 
For simple cases and/or relatively inexperienced programmers I actually
prefer that JPA be used. For the large majority of complex cases I
believe that JPA also is the choice. There is only s small percentage of
complex OR mapping situations where I think an experienced programmer
can make a case for simple mapping tools.

AHS
-- 
A fly was very close to being called a "land," cause that's what they do
half the time.
-- Mitch Hedberg

[toc] | [prev] | [next] | [standalone]

#14077

On 5/1/2012 6:29 AM, Arved Sandstrom wrote:

> On 12-04-30 11:27 PM, markspace wrote:
>> If the authors of the projects say it's not ORM, I'll choose to believe
>> them.

> To an extent I'm happy to go with what authors say also. More precisely
> DBUtils *is* an ORM - just look at the available ResultSetHandler


Right-o.  I knew what Lew meant, but I still found his statement to be 
inaccurate.  It was clearly an exaggeration to say that dbutils is an 
ORM just like JPA or Hibernate.  JPA and dbutils are practically on 
different planets.  They solve a similar problem, but they take very 
different approaches.


> I prefer to differentiate between basic OR mappers like DBUtils that do


This is good, I like the term "mapper" here instead of ORM.  Data Mapper 
is a design pattern.  Specifically it's a lighter-weight one that DAO, 
so it's a good fit to what dbutils is trying to accomplish.

<http://martinfowler.com/eaaCatalog/dataMapper.html>
<http://rrees.wordpress.com/2009/07/11/the-dao-anti-patterns/>

[toc] | [prev] | [next] | [standalone]

#14140

On Tuesday, May 1, 2012 8:57:28 AM UTC-7, markspace wrote:
> On 5/1/2012 6:29 AM, Arved Sandstrom wrote:
> 
> > On 12-04-30 11:27 PM, markspace wrote:
> >> If the authors of the projects say it's not ORM, I'll choose to believe
> >> them.
> 
> > To an extent I'm happy to go with what authors say also. More precisely
> > DBUtils *is* an ORM - just look at the available ResultSetHandler
> 
> 
> Right-o.  I knew what Lew meant, but I still found his statement to be 
> inaccurate.  It was clearly an exaggeration to say that dbutils is an 
> ORM just like JPA or Hibernate.  JPA and dbutils are practically on 

I didn't say "just like JPA or Hibernate".

Nor did the OP.

> different planets.  They solve a similar problem, but they take very 
> different approaches.
> 
> 
> > I prefer to differentiate between basic OR mappers like DBUtils that do
> 
> 
> This is good, I like the term "mapper" here instead of ORM.  Data Mapper 
> is a design pattern.  Specifically it's a lighter-weight one that DAO, 
> so it's a good fit to what dbutils is trying to accomplish.

The "M" in "ORM" stands for "mapping" or "mapper".

> <http://martinfowler.com/eaaCatalog/dataMapper.html>
> <http://rrees.wordpress.com/2009/07/11/the-dao-anti-patterns/>

By "monolithic" I mean, in the case of JPA, creating one data-access layer which sits between all object code and all DB access. Using a single 'EntityManager' to handle many things for a long time is monolithic, and causes persistence sessions to fill and get slow. Funneling everything through a single data-access construct suffers from the "God object" complex.

"Non-monolithic" means, for example, a separate data-access class for each module that needs access. So your "FooOrder" module will have a data-access object with its own 'EntityManager', "BazHistoryMarker" will have another, and so on.

This makes data access easier to reason about and to troubleshoot. It also obviates various run-time problems.

As for "lightweight", I have only heard, "not many API calls" as a metric. How does dbutil rate as lighter than JPA by that metric? Even the short snippet posted here of dbutil code looks messier and harder to set up than JPA.

JPA is the first ORM (sorry, folks, dbutil is an ORM) I've found worth using. I avoid Hibernate's JPA because it's too easy to slip into pre-JPA idioms with it, which in my view ruin its utility when you do.

JPA has shown itself the leanest (in terms of programmer effort) and slickest way to handle its intended use cases (e.g., not bulk inserts) of anything I've tried.

Unless it's abused horribly, which I've also seen. But the abusers of JPA are no better with JDBC, other Java idioms, and I predict nor with dbutils.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#14185

On 5/2/2012 11:16 AM, Lew wrote:
>
> The "M" in "ORM" stands for "mapping" or "mapper".


I always thought it was "management" but I don't see anything on the web 
to support my recollection, so I guess not.


> Using a
> single 'EntityManager' to handle many things for a long time is
> monolithic, and causes persistence sessions to fill and get slow.
> Funneling everything through a single data-access construct suffers
> from the "God object" complex.


OK, I guess it never occurred to me that someone would do something like 
that.  I'll have to keep an eye out for that little anti-pattern.


> "Non-monolithic" means, for example, a separate data-access class for
> each module that needs access. So your "FooOrder" module will have a
> data-access object with its own 'EntityManager', "BazHistoryMarker"
> will have another, and so on.


This is the way DAOs always naturally decompose for me.  I can't see how 
someone would come up with a different idea.

Thanks for taking the time to describe those terms.

[toc] | [prev] | [next] | [standalone]

#14112

On 4/30/2012 9:03 PM, Lew wrote:
> On Monday, April 30, 2012 2:55:51 PM UTC-7, 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
>
> That's funny. You say, "No ORM", then immediately describe the ORM library you're using.

>> something light-weight [sic] to help me out.  I found the Apache commons
>> dbutils project:
>>
>> <http://commons.apache.org/dbutils/>
>>
>> This makes reading a bean much much easier.  It does most of the column
>> to property matching for you and will read an entity into a bean with
>> only a few lines of code.  Here's a (mostly) complete example from my
>> little project:
>>
>>      public UserBean getByUsername( String name ) {
>>         QueryRunner run = new QueryRunner( dataSource );
>>         BeanHandler<UserBean>  handler = new BeanHandler( UserBean.class );
>>         UserBean user = null;
>>         try {
>>          user=run.query( sqlStatements.getProperty( LOGIN_BY_USERNAME ),
>>                    handler, name );
>>         } catch( SQLException ex ) {
>>            Logger.getLogger( UserDataMapper.class.getName() ).
>>                    log( Level.SEVERE, null, ex );
>>         }
>>         return user;
>>      }
>>
>>
>> That's a lot less 'faffing about' reading the fields of a ResultSet into
>> a simple bean, and a much higher signal-to-noise ratio imo.
>
> Yes, that's the advantage of ORMs generally.
>
> I prefer EclipseLink and OpenJPA, myself. They go so far as to abstract away even that pseudo-SQL, for the common case. You write some annotations and Bob's your uncle.
>
>> The problem is, this only works for reading a simple entity.  There
>> doesn't seem to be any equivalent for update, create, or delete.
>>
>> So my question is: does any have experience with dbutils and see's
>> something I'm missing?  Would you take a look at the docs even if you
>> don't have experience with dbutils?
>>
>> And: is there a better, light-weight non-ORM package that you might
>> recommend instead?  Something a bit more complete.
>
> How is the one you're using not ORM?
>
> It maps between objects and relational entities. Object-to-relational mapping. Q.E.D.

I would say that it depends on how he is using the this package.

The key phrase here is "it maps".

If the code is using BeanHandler or BeanListHandler, then the
package store the data in the fields and I believe it is an ORM.

Using fieldname=columnname convention is not less ORM than using
annotations or XML config file.

If the code is using one of the other handlers where the developer
writes the mapping code it is "I map" not "it maps" and it is not ORM.

Arne

[toc] | [prev] | [next] | [standalone]

#14085

On 4/30/12 2:55 PM, markspace wrote:
> Hey all,
>
> 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:
[snip].
> That's a lot less 'faffing about' reading the fields of a ResultSet into
> a simple bean, and a much higher signal-to-noise ratio imo.
>
> The problem is, this only works for reading a simple entity. There
> doesn't seem to be any equivalent for update, create, or delete.
>
> So my question is: does any have experience with dbutils and see's
> something I'm missing? Would you take a look at the docs even if you
> don't have experience with dbutils?
>
> And: is there a better, light-weight non-ORM package that you might
> recommend instead? Something a bit more complete.
Why avoid ORM? They do exactly what you're asking, and do it fairly well 
for simple situations. If you find something that does what you're 
asking without "faffing about", then you've found an ORM. You can always 
use introspection to do that work yourself for creates/updates, but at 
that point you've created a rudimentary ORM.
>
> Anyway, I'm in the middle of adding basic update and create, and it's
> actually going well. (It'd be going better if I weren't some clumsy with
> SQL syntax.) But I thought I'd ask to see what other ideas the folks
> here on this news group might have.
I know this isn't the answer you're looking for, but look into ORMs. 
Unless you have a good reason to keep it low level, but realistically 
there are only three reasons to do that, educational exercise or you're 
building your own ORM, fear of the unknown.

Good luck with your endeavors,
Daniel.

[toc] | [prev] | [next] | [standalone]

#14093

On 5/1/2012 10:32 AM, Daniel Pitts wrote:

> there are only three reasons to do that, educational exercise


This is my intent exactly.  What other options exist and to what extent 
should I pay attention to them?  That's what I'm working out.


>  fear of the unknown.


This I've seen in the industry and in potential employers.  My intent is 
also defensive.  Put a bit of something else on the resume, be able to 
say I've done.  I don't have to recommend it;  I'll volunteer to point 
out it's not best practice.  But if they're paying and they insist it's 
what they want, then the buyer gets what the buyer wants.

[toc] | [prev] | [next] | [standalone]

#14105

On 5/1/12 11:22 AM, markspace wrote:
> On 5/1/2012 10:32 AM, Daniel Pitts wrote:
>
>> there are only three reasons to do that, educational exercise
>
>
> This is my intent exactly. What other options exist and to what extent
> should I pay attention to them? That's what I'm working out.
>
>
>> fear of the unknown.
>
>
> This I've seen in the industry and in potential employers. My intent is
> also defensive. Put a bit of something else on the resume, be able to
> say I've done. I don't have to recommend it; I'll volunteer to point out
> it's not best practice. But if they're paying and they insist it's what
> they want, then the buyer gets what the buyer wants.

Fair enough :-)

Best of luck in that case ;-)

[toc] | [prev] | [next] | [standalone]

#14106

On 12-05-01 07:26 PM, Daniel Pitts wrote:
> On 5/1/12 11:22 AM, markspace wrote:
>> On 5/1/2012 10:32 AM, Daniel Pitts wrote:
>>
>>> there are only three reasons to do that, educational exercise
>>
>>
>> This is my intent exactly. What other options exist and to what extent
>> should I pay attention to them? That's what I'm working out.
>>
>>
>>> fear of the unknown.
>>
>>
>> This I've seen in the industry and in potential employers. My intent is
>> also defensive. Put a bit of something else on the resume, be able to
>> say I've done. I don't have to recommend it; I'll volunteer to point out
>> it's not best practice. But if they're paying and they insist it's what
>> they want, then the buyer gets what the buyer wants.
> 
> Fair enough :-)
> 
> Best of luck in that case ;-)

I don't think we have to be negative about recommending or choosing
something like DBUtils. Is anyone going to argue that it's never
appropriate to use JDBC directly? I doubt it. And most Java developers
accept that a high-powered JPA ORM is often OK.

So it stands to reason that sometimes something in between is also OK.
Either DBUtils, or something more robust like MyBatis.

I'm looking at DBUtils, with a ~50K JAR and about 30 classes and
interfaces, and EclipseLink 2.2, with a ~6 MB JAR and a lot of classes
and interfaces. I can think of situations where I'd like to do
uncomplicated OR mapping, *and* it's important to keep the size down.
I'll pick something like DBUtils, and not be apologetic about it either.

AHS
-- 
A fly was very close to being called a "land," cause that's what they do
half the time.
-- Mitch Hedberg

[toc] | [prev] | [next] | [standalone]

#14113

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

I doubt that you will save any code in your app.

I doubt that the less memory usage will be noticeable.

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.

And some of the capabilities (like caching) could become
very handy in the future.

Arne

[toc] | [prev] | [next] | [standalone]

#14118

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.

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

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.

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

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.

> Arne
> 

AHS

1. Well, heavyweight ESBs too. But I surely do prefer the lightweight
ones. :-)

2. Counts on non-empty lines, so including comments, using
find/grep/awk. So somewhat greasy but not that off the mark.
-- 
A fly was very close to being called a "land," cause that's what they do
half the time.
-- Mitch Hedberg

[toc] | [prev] | [next] | [standalone]

#14124

Arved Sandstrom <asandstrom3minus1@eastlink.ca> wrote:
> 
> Precisely so that you don't have a full-blown ORM with either a native
> API or JPA.

Going off on a slight tangent here, but I've noticed a tendency in
projects that uses a full ORM to do the data modelling away from the
database and let the Java object model "drive" the database schemas.

Now, that's not necessarily a problem -- for many projects that'll
still be within "good enough" -- but it's not necessarily _not_ a
problem either.

- 
Leif Roar Moldskred

[toc] | [prev] | [next] | [standalone]

#14201

On 5/1/2012 11:22 PM, Leif Roar Moldskred wrote:
> Arved Sandstrom<asandstrom3minus1@eastlink.ca>  wrote:
>>
>> Precisely so that you don't have a full-blown ORM with either a native
>> API or JPA.
>
> Going off on a slight tangent here, but I've noticed a tendency in
> projects that uses a full ORM to do the data modelling away from the
> database and let the Java object model "drive" the database schemas.

True.

And for a bad reason. ORM's work best that way.

Arne

[toc] | [prev] | [next] | [standalone]

#14200

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

[toc] | [prev] | [next] | [standalone]

#14212

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.

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

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

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

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

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.

AHS
-- 
A fly was very close to being called a "land," cause that's what they do
half the time.
-- Mitch Hedberg

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web