JEPLDroid JDBC ORM: el port a Android de JEPLayer

He publicado JEPLDroid, ORM basado en JDBC para Android.

La primera versión es la v1.1 y no la 1.0 porque JEPLDroid está alineado con JEPLayer  compartiendo buena parte de su código.

En pocas palabras JEPLDroid = JEPLayer - JTA

JEPLDroid tiene dos modos de funcionamiento:

1) Con un driver JDBC compatible Android funciona igual que su hermano mayor JEPLayer

2) Cuando se detecta el uso de SQLDroid, el famoso driver JDBC para el SQLite embebido de cualquier dispositivo Android, JEPLDroid funciona intentando evitar en lo posible las limitaciones de este driver y en general las limitaciones impuestas por la API de Android de acceso a SQLite que es en la que se basa SQLDroid.

Imagino el punto 2) será el uso más habitual de JEPLDroid el cual tiene algunas limitaciones que como se verá más adelante tampoco son excesivamente importantes:

Limitaciones con SQLDroid y el SQLite de Android

* Métodos tal y como JEPLDALQuery.executeUpdate() devuelven siempre cero, no el número de registros involucrados. Esto es porque la API de SQLite no da esta información. Esto afecta a métodos que sirven para detectar resultados inexperados tal y como JEPLDALQuery.setStrictMinRows(int) and JEPLDALQuery.setStrictMaxRows(int), dichos chequeos en operaciones de inserción, eliminación o actualización se ignorarán (preferible a que siempre den error) permitiendo así que el código persistente sea prácticamente el mismo con JEPLayer que con JEPLDroid.

* El método JEPLDALQuery.getGeneratedKey(Class<U>) no ejecuta una única sentencia SQL sino que además de ejecutar la sentencia de inserción, ejecuta también SELECT LAST_INSERT_ROWID(). Esta no es realmente una limitación pues es el uso normal de SQLite, es más aporta una API más directa y agnóstica que haciendolo via JDBC en dos sentencias con SQLDroid (la obtención de claves normal con JDBC no funciona en SQLite).

Pero no sólo hay limitaciones también mejoras a SQLDroid

* En SQLDroid no está implementado el método PreparedStatement.setObject(int column,Object param), esto no es problema en JEPLDroid, se pueden usar métodos tal y como JEPLDALQuery.addParameters(Object...) JEPLDroid se encarga de llamar al método apropiado de SQLDroid de acuerdo con el tipo de dato.

* JEPLDALQuery.getGeneratedKey(Class<U>) funciona normalmente pese a no estar basado en PreparedStatement.getGeneratedKeys() que es lo normal en JDBC.

* Es posible el posicionamiento absoluto en el cursor de resultado. Este es una carencia grave y absurda de SQLDroid pues existe esta API en Android SQLite, es decir en SQLDroid ResultSet.absolute(int) no está implementado, este método es fundamental para obtener un rango de resultados de una consulta (la típica consulta paginada) sin cargar la tabla entera o hasta el límite del rango que se necesita. En JEPLDroid se hace el posicionamiento absoluto directamente en Android SQLite tal que se pueda ejecutar una llamada de este tipo:

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

Aquí teneis un artículo sobre JEPLayer en javaHispano.

Todos los ejemplos deberían funcionar sin modificación exceptuando los basados en JTA (exceptuando el SQL que en algún ejemplo es para MySQL).

En la distribución que incluye el código fuente se incluye una aplicación normal Android que crea una base de datos SQLite al vuelo ejecuta una batería de tests (tomados de JEPLayer), sirve de ejemplo como punto de partida para configurar tu propio código basado en JEPLDroid, SQLDroid y SQLite.

Que lo disfruteis.