Apache JDBC utils

Discussion in 'Java' started by markspace, Apr 30, 2012.

  1. markspace

    markspace Guest

    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!
    markspace, Apr 30, 2012
    #1
    1. Advertising

  2. 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
    Arved Sandstrom, May 1, 2012
    #2
    1. Advertising

  3. markspace

    markspace Guest

    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.
    markspace, May 1, 2012
    #3
  4. markspace

    Lew Guest

    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 andBob'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
    Lew, May 1, 2012
    #4
  5. markspace

    markspace Guest

    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.
    markspace, May 1, 2012
    #5
  6. 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
    Arved Sandstrom, May 1, 2012
    #6
  7. markspace

    markspace Guest

    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/>
    markspace, May 1, 2012
    #7
  8. markspace

    Daniel Pitts Guest

    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.
    Daniel Pitts, May 1, 2012
    #8
  9. markspace

    markspace Guest

    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.
    markspace, May 1, 2012
    #9
  10. markspace

    Daniel Pitts Guest

    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 ;-)
    Daniel Pitts, May 1, 2012
    #10
  11. 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
    Arved Sandstrom, May 1, 2012
    #11
  12. markspace

    Arne Vajhøj Guest

    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
    Arne Vajhøj, May 2, 2012
    #12
  13. markspace

    Arne Vajhøj Guest

    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
    Arne Vajhøj, May 2, 2012
    #13
  14. 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
    Arved Sandstrom, May 2, 2012
    #14
  15. In article <jnn1pc$33c$>, markspace <-@.> wrote:

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


    Having always used JDBC, I wanted to see what a persistence unit looked
    like. I used the "New Entity Classes from Database Wizard" in NetBeans
    to generate an entity for a database table named CUSTOMER and clicked
    the persistence unit button to generate a JPA controller.

    Entity -> Customer.java
    Persistence unit -> CustomerJpaController.java

    Then I used these two classes to fill a JComboBox model, as shown here:

    <http://stackoverflow.com/a/2531942/230513>

    The example was easy to create, and I can see several things:

    1. The queries, getters, setters and annotations generated in the entity.

    2. The findCustomerXxx, create, edit and destroy methods generated in
    the controller, which appear to correspond roughly to select, insert,
    update and delete.

    --
    John B. Matthews
    trashgod at gmail dot com
    <http://sites.google.com/site/drjohnbmatthews>
    John B. Matthews, May 2, 2012
    #15
  16. markspace

    Jan Burse Guest

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


    The example that you have posted involves a lot of classes.
    You can build a framework that exposes only one class
    XXXBean per table XXX, and that features bulk update,
    delete and select, which you usually don't get via ORM,
    or where you usually bypass the ORM.

    The idea is as follows:
    - bulk update: Objects are not loaded, bean is just
    a facade to an SQL updates statement. No DB
    client roundtrips.
    - bulk delete: Objects are not loaded, bean is just
    a facade to an SQL delete statement. No DB
    client roundtrips.
    - bulk select: Only one object is loaded at a time,
    but the same object holder is reused, bean is
    just a facade to a SQL select statement and a
    cursor.

    The idea shares the same benefits with an ORM:
    - possibility to have application specific column
    names and types.
    - transparent dealing with SQL dialects, i.e.
    issues such as boolean representation, string
    encoding etc...
    - Since colums correspond to methods, its easy
    to find usages in your application, i.e. cross
    referencing
    - Since columns correspond to methods, and these
    have types, it is easy to find compilation erros,
    i.e. wrong type use of columns etc..

    So how will the API of such a XXXBean look like. Well
    it will have the following methods:

    whereYYY(TTT); Establish condition on column YYY
    calcYYY(TTT); Establish value on column YYY
    TTT getYYY(); Retrieve value of column YYY
    list(); Open cursor
    next(); Advance cursor
    close(); Close cursor
    update(); Bulk update
    insert(); Single insert
    delete(); Bulk delete

    For CRUD the API is used as follows:

    C R U D
    whereYYY(TTT); - x x x
    calcYYY(TTT); x - x -
    getYYY(); - x - -
    list(); - x - -
    next(); - x - -
    close(); - x - -
    update(); - - x -
    insert(); x - - -
    delete(); - - - x

    The framework can be extended to allow for column sorting,
    aggregate functions, complex value expressions, complex
    conditions, transactions, select caching, insert buffering,
    etc.. The framework is not per se target towards proving
    joins over tables. But it can be also enhanced in this
    direction, even with distributed transactions.

    Concerning joins, the participant XXXBeans need not come
    from the same database. Deployment descriptions can define
    the JDBC connection for individual XXXBeans. Here is how one
    might copy from one table AAA column CCC to another table BBB
    columnd DDD, where the two tables need not reside on the
    same database.

    AAABean ab=new AAABean();
    ab.list();
    BBBBean bb=new BBBBean();
    while (ab.next()) {
    bb.calcDDD(ab.getCCC());
    bb.insert();
    }
    ab.close();

    I am currently using such a framework called Matula. A very
    old version which had ORM in mind is public (*). But now
    its not classical ORM. Current drawback: Does not provide
    delayed optimistic transactions as in Hybernate, since there
    is no local object store.

    Bye

    (*)
    http://www.xlog.ch/matula/
    Jan Burse, May 2, 2012
    #16
  17. On 12-05-02 12:37 AM, John B. Matthews wrote:
    > In article <jnn1pc$33c$>, markspace <-@.> wrote:
    >
    >> And: is there a better, light-weight non-ORM package that you might
    >> recommend instead? Something a bit more complete.

    >
    > Having always used JDBC, I wanted to see what a persistence unit looked
    > like. I used the "New Entity Classes from Database Wizard" in NetBeans
    > to generate an entity for a database table named CUSTOMER and clicked
    > the persistence unit button to generate a JPA controller.
    >
    > Entity -> Customer.java
    > Persistence unit -> CustomerJpaController.java


    I'll have to run NetBeans tonight to remind myself of what it produces
    as a "JPA controller". :) Bear in mind, persistence units are actually
    what are described in persistence.xml (one or more).

    > Then I used these two classes to fill a JComboBox model, as shown here:
    >
    > <http://stackoverflow.com/a/2531942/230513>
    >
    > The example was easy to create, and I can see several things:
    >
    > 1. The queries, getters, setters and annotations generated in the entity.
    >
    > 2. The findCustomerXxx, create, edit and destroy methods generated in
    > the controller, which appear to correspond roughly to select, insert,
    > update and delete.
    >

    Don't get me wrong, I'm a JPA enthusiast. Before it showed up I used the
    native APIs in Toplink, Toplink Essentials and Hibernate, and even those
    usually would win out over straight JDBC.

    But what you did above just scratches the surface. It's now your
    responsibility to read and understand the JPA specification and get the
    lay of the land for the APIs. I mean "your" in the general sense here.

    You've always used JDBC, you say. You're aware then that you have to
    know quite a lot to use that well. You need to know a lot more - *plus*
    understanding JDBC, IMO - to use JPA well. We've been throwing around
    terms like conceptual or architectural weight - with JPA you pull in a
    fair bit of that.

    I don't believe that *you* would stop here - in fact you'd go ahead and
    read the spec - but I've seen a fair few programmers that think that's
    mostly all there is to JPA: use the IDE to generate from the DB, or vice
    versa. They always run into problems sooner or later.

    AHS
    --
    A fly was very close to being called a "land," cause that's what they do
    half the time.
    -- Mitch Hedberg
    Arved Sandstrom, May 2, 2012
    #17
  18. markspace

    markspace Guest

    On 5/2/2012 3:22 AM, Jan Burse wrote:
    > markspace schrieb:
    >> And: is there a better, light-weight non-ORM package that you might
    >> recommend instead? Something a bit more complete.

    >
    > The example that you have posted involves a lot of classes.



    Really? Two classes is a lot? I'm not being sarcastic here, I don't
    understand how this is a lot. I used QueryRunner and BeanHandler, that
    seems pretty pithy to me.


    > You can build a framework that exposes only one class



    While mucking about with the reflection API is fun, the goal is to avoid
    building my own framework. ;)


    > http://www.xlog.ch/matula/



    Ah ha! Thanks, I'll check that out.
    markspace, May 2, 2012
    #18
  19. markspace

    Lew Guest

    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-accessobject 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
    Lew, May 2, 2012
    #19
  20. markspace

    Jan Burse Guest

    markspace schrieb:
    > While mucking about with the reflection API is fun, the goal is to avoid
    > building my own framework. ;)


    *NO* reflection API was used at all, *NO* injection
    pattern was used, also no penguins where harmed. The
    framework consists of what would one call XDoclet today.

    But instead of XDoclet I use JSP to generate via
    its output the Java code for the XXXBeans. The
    input are some property files and the JDBC access
    to the meta data of the already existing DB.

    +--------+ +-------------+
    | DB | | .properties |
    +--------+ +-------------+
    | |
    ------ -----
    | |
    v v
    +--------+
    | JSP |
    +--------+
    |
    v
    +------------+
    | XXXBean |
    +------------+

    Some part of the framework deals with invoking JSP
    without browser attention in kind of batch mode. But
    using JSP to generate Java code is straight forward.
    Check out genbean.jsp, it starts with:

    public class <%=table%>Bean extends util.bean.BeanUtil {
    private util.bean.ColumnDescriptor[] columndescriptors;

    And as you might expect it can generate Java code and
    place what table has a value in front of Bean. Or something
    more elaborate:

    <%
    generator.bean.Column col=new generator.bean.Column();
    col.setTable(tab);
    col.list();
    while (col.next()) {
    %> private <%=col.getType()%> <%=col.getName()%>=<%=col.getNullConst()%>;
    <%
    }
    col.close();
    %>

    The above iterates through the columns of the given table,
    and the generates variable declarations.

    Bye
    Jan Burse, May 2, 2012
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Keith Wansbrough

    Re: jdbc help:sun.jdbc.odbc.JdbcOdbcDriver

    Keith Wansbrough, Aug 16, 2004, in forum: Java
    Replies:
    0
    Views:
    751
    Keith Wansbrough
    Aug 16, 2004
  2. Betty
    Replies:
    1
    Views:
    9,863
    Juha Laiho
    May 21, 2005
  3. Jesus M. Salvo Jr.
    Replies:
    2
    Views:
    4,160
    robert
    Feb 11, 2006
  4. arm developer
    Replies:
    0
    Views:
    356
    arm developer
    Jun 3, 2004
  5. Eirikur Hallgrimsson
    Replies:
    3
    Views:
    157
    Gavin Sinclair
    Oct 10, 2004
Loading...

Share This Page