I'm the father of ItsNat AJAX Java web framework, JNIEasy, LAMEOnJ, JEPLayer and JEPLDroid libraries (and very old stuff like XPDOM), supporter of the Single Page Interface (SPI) paradigm, writer of the SPI manifesto and currently Android native guy. Jose Maria has posted 28 posts at DZone. You can read more from them at their website. View Full User Profile

JEPLDroid - A JDBC-based ORM for Android/SQLite

  • submit to reddit

I've released JEPLDroid , a JDBC-based ORM for Android.

The first version is v1.1 and not 1.0 because it is aligned with JEPLayer   JEPLDroid shares much of their code.

In short JEPLDroid = JEPLayer - JTA

JEPLDroid has two operating modes:

  1. With a JDBC driver running on Android it works just like its big brother JEPLayer
  2. When using alongside SQLDroid , the famous JDBC driver for SQLite embedded in any Android device. JEPLDroid detects SQLDroid and tries to avoid some limitations of this driver and general limitations of the Android API access SQLite it is based on SQLDroid.

I guess the point 2) will be the most common use of JEPLDroid which has some limitations, as discussed below they are not overly important:

Limitations when using SQLDroid Android and SQLite

  • Methods such as JEPLDALQuery.executeUpdate () always return zero, not the number of records involved. This is because the SQLite API does not provide this information. This affects methods that detect unexpected results as JEPLDALQuery.setStrictMinRows (int) and JEPLDALQuery.setStrictMaxRows (int). These checks on insert, delete or update sentences are ignored (always preferable to throw errors) allowing persistent code to be the same in desktop (with JEPLayer) and in Android (with JEPLDroid).
  • The method JEPLDALQuery.getGeneratedKey (Class <U>) does not execute a single SQL statement (the SQL insert statement), also executes LAST_INSERT_ROWID SELECT (). This is not really a limitation because it is the normal use of SQLite, it provides a more direct and agnostic API that doing two statements via JDBC with SQLDroid (because conventional JDBC code for automatic key generation does not work in SQLite).

But not only there are limitations, there are improvements of JEPLDroid over SQLDroid:

  • In SQLDroid the method PreparedStatement.setObject (int column, Object param) is not implemented, this is no problem in JEPLDroid methods like JEPLDALQuery.addParameters (Object. ..)  can be used as usual. JEPLDroid is responsible for calling the appropriate method of SQLDroid according to the data type.
  • JEPLDALQuery.getGeneratedKey (Class <U>) operates normally despite not being based on PreparedStatement.getGeneratedKeys () which is the usual in JDBC.

  • Absolute positioning is possible in the cursor result. This is a serious and absurd lack of SQLDroid because this function is in Android SQLite API, that is ResultSet.absolute (int) is not implemented in SQLDroid. This method is critical to obtain a range of results from a query (the typical paged query) without loading the entire table or loading the table to the upper limit of the range. In JEPLDroid absolute positioning is done directly in Android SQLite so that you can execute code like this: 

public List<Contact> selectJEPLDAOQueryRange(int from,int to)
return dao.createJEPLDAOQuery("SELECT * FROM CONTACT")
.setMaxResults(to - from)

Here you have an article about JEPLayer   here at Java DZone.

All examples should work without modification except for JTA-based (and some SQL query based on MySQL specific SQL).

The JEPLDroid source code distribution includes a standard Android application that creates an SQLite database on the fly and runs a battery of tests (taken from JEPLayer), it serves as an example as a starting point for setting up your own code based on JEPLDroid, SQLDroid and SQLite.

Enjoy it.

Published at DZone with permission of its author, Jose Maria Arranz.
