JBossDeveloper

Guess this is just one of those religious wars that it is impossible to end... ;-)

Francisco Peredo wrote on Nov 25, 2009 02:13:

Gavin King wrote on Nov 25, 2009 02:06:


I didn't say use JPA I said use a JDBC framework that wraps it. Lots of people like iBATIS, but that might be too high-level for your taste. Their are other, less-abstract options.

iBATIS is your idea of something better than Spring-JDBC? sigh

Definitely not. I said lots of people. I did not say I. I just used it as an example of a less-than-ORM solution that does not require the use of funny inner classes to get resource management and exception handling.

In an environment like Weld, with interceptors and injection of stateful objects, the use of inner classes for access to transactional resources is completely unnecessary (and intrusive).

Gavin King wrote on Nov 25, 2009 06:21:


In an environment like Weld, with interceptors and injection of stateful objects, the use of inner classes for access to transactional resources is completely unnecessary (and intrusive).

Well, but since an environment like Weld has been available for years.... ;-)... Of course not :-P. That is why being the first to create something Weld-JDBC could be very exiting.. the thing is to come up with something that takes proper advantage of Weld features... and AFAIK since Weld has not existed for years, we need to come up with something new...

So Arbi... any proposals on how to take advantage of Weld great features to create a revolutionary Weld-JDBC? It has to be something that makes low level JDBC programming more comfortable, but at the same time takes advantage of interceptors and injection of stateful objects...

A great JDBC fwk, IMO, would look approximately something like:

import org.seamframework.sql.Table;
import org.seamframework.sql.Column;

/**
 * Typesafe representation of the "users" table
 */
public class users {
   public static final Table<users> table = new Table<users>("users");
   public static final Column<users,String> username = new Column<username,String>("username");
   public static final Column<users,String> name = new Column<name,String>("name");
   public static final Column<users,String> password = new Column<password,String>("password");
}

import static org.seamframework.sql.Expressions.*;

import org.seamframework.sql.Session;
import org.seamframework.sql.Query;

public class Login {

   @Produces @Current User user;

   @Inject Session session;

   Query query;
   Selection<String> nameSelection;
   Parameter<String> usernameParam;
   Parameter<String> passwordParam;

   @PostConstruct 
   void init() {
      query = session.createQuery();
      From<users> fromUsers = query.from(users.table);
      Selection<String> nameSelection = fromUsers.get(users.name)
      query.select(nameSelection);
      usernameParam = query.parameter(String.class);
      passwordParam = query.parameter(String.class);
      query.where( and( equals( fromUsers.get(users.username), usernameParam ),
                    equals( fromUsers.get(users.password), passwordParam ) ) );
   }

   public void login(String un, String pw) {
      Tuple tuple = session.execute(query)
                           .setParameter(usernameParam, un)
                           .setParameter(passwordParam, pw)
                           .getRow();
      String name = tuple.get(nameSelection);
      user = new User(un, name, pw);
   }

}

Note that, of course, a simple tool that reads the database metadata could automate the generation of the table classes.

Looks nice, a bit JPA 2 like syntax.

(PS. @Current is no longer supported) ;-)

I have to admit it looks cool (it reminds me of JPA 2.0 typesafe CriteriaQuery )

A far reaching analysis of something that starts with

would look approximately something like

consider the number of lines of code required to accomplish this in your version vs....

Probably a few more characters in my solution. On the other hand, this code is typesafe and 100% toolable. Which means that my IDE can write most of it for me, and tell me when I mistype things. So, after balancing the various factors, this solution is MUCH more productive.

performance vs. the other JDBC fwk solutions

And? Why should it be any different?

don't forget full CRUD is required, this example only illustrates a query/select

Fullselects are the difficult case. Updates/deletes are trivial. The code for an update/delete is much simpler, since I can use direct column references, I don't need to alias them through a From.

exception handling, this is one area where Spring does a good job: "The Spring Framework's handling of SQLException is one of its most useful features in terms of enabling easier JDBC development and maintenance. The Spring Framework provides JDBC support that abstracts SQLException and provides a DAO-friendly, unchecked exception hierarchy."

Utter nonsense and dishonest false advertising. Oracle has hundreds (thousands?) of error codes, and the Spring guys have not gone through them all and figured out which ones are constraint violations, which are connection problems, which are .... Instead they let you figure out all this yourself and write it in a text file. Which is, in practice, an impossible job. Which they know. Which is why they do not do it for you and provide you with the text file out-of-the-box.

Of course, our JDBC framework could include the following code:

catch (SQLException sqle) {
    throw Class.forName( lookupExceptionClassInUserWrittenTextFile( sqle.getErrorCode() ) ).newInstance();
}

And we would have reproduced what Spring offers in this area.

Automatic connection closing (and other boiler-plate code) is obviously a hard requirement to be handled by the fwk.

Pffffff. It's a trivial requirement which I can solve in my framework with two lines of code in a @Disposes method. Did you see any connection handling in the code above?

Batch update support in the API

Also basically trivial.

The point is that this solution/fwk needs to be better in every possible way

Nonsense. It only needs to be better overall. Which it quite obviously is.

I mean, seriously guys. The Spring stuff is trivial and not even very elegant. I guess it's easier for me to see that, since I spent half my career thinking about data access and designing data access APIs. But even so...

Utter nonsense and dishonest false advertising. Oracle has hundreds (thousands?) of error codes, and the Spring guys have not gone through them all and figured out which ones are constraint violations, which are connection problems, which are .... Instead they let you figure out all this yourself and write it in a text file. Which is, in practice, an impossible job. Which they know. Which is why they do not do it for you and provide you with the text file out-of-the-box.

Oh, and by the way: the latest rev of JDBC actually has built-in support for exception subtypes. Which is a much better solution, since the JDBC implementer actually does have enough knowledge of the product to compile a robust set of error codes.

The proposal is theoretically nice but I must say that Arbi has a good point about its verbosity. Honestly I don't see myself explaining to my developers that they have to write all this to execute a simple SQL query. And without proper tooling, type-safety is limited because nothing can ensure that the database table or column names are correct in the metadata class.

I guess I would be satisfied enough with something like this :

public void login(String un, String pw) {
   Tuple tuple = session.execute("select name from user where username = :username and password = :password")
                        .setParameter("username", un)
                        .setParameter("password", pw)
                        .getRow();
   String name = tuple.get("name");
   user = new User(un, name, pw);
}

Perhaps both formats could be supported. We could then document a recovery plan for JdbcTemplate addicts

1. Denial


2. Non-typesafe version


3. Typesafe version


4. JPA and JTA