Apache JDBC utils

[markspace]

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!

 

[Arved Sandstrom]

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

 

[markspace]

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

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

Thanks for that, I'll check it out.

 

[Lew]

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.

 

[markspace]

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.

 

[Arved Sandstrom]

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.

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


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

 

[markspace]

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

 

[Daniel Pitts]

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.

 

[markspace]

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.

 

[Daniel Pitts]

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.




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

 

[Arved Sandstrom]

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

 

[Arne Vajhøj]

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]

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

 

[Arved Sandstrom]

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.

 

[John B. Matthews]

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.

 

[Jan Burse]

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/

 

[Arved Sandstrom]

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

 

[markspace]

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.

 

[Lew]

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.




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.

 

[Jan Burse]

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