Well known persistence frameworks like Hibernate generally approach the persistence layer from the Java point of view and try to hide the SQL nature of the database. This has repeatedly been a source of programmers' headache, and we think that it is wrong to ignore the technical nature of the database when working with the persistence layer.

With sqlapi4j we approach the problem from the database/SQL point of view. We create a DSL which we want to look and behave like plain SQL and thus follows the principle of least surprise. Our approach is type safe (in contrast to, e. g., Hibernate criteria API) and even null safe, if you use JSR305 annotations and FindBugs.

A working example of an application using SQLApi4J with Guice, C3P0 Pooling, Transactions and Dao Pattern.

You should have a look at the demo sourcecode to get a feeling for how to integrate the SQL Api and for how to use it.

The core DSL of the SQL API. You will use this package to formulate your table descriptions and your queries. Works directly on connections. Look at dao and transaction layers if you do not want to do the connection stuff "by hand".

Simple Layer to handle @Transaction annotations and generally to handle Transactional stuff. You will need to provide a DataSource. Most useful in combination with sqlapi4j-dao

Guice Module to help with binding the sqlapi4j-tx classes.

sqlapi4j-dao offers a bunch of convenience wrappers making the everyday life much easier.

Needs a TransactionTemplate. sqlapi4j-tx provides an implementation of the TransactionTemplate, but it is perfectly fine to use a different transaction-handling instead. For example you could use spring transactions and implement your own (very simple) TransactionTemplate to integrate spring transactions with sqlapi4j-dao.

Also needs an SqlExecutor, which is defined in sqlapi4j-core and depends on the database type (hibernate, h2, oracle etc) you need to talk to.