Migrar WebSQL a SQLite nativo

[jrvidal]

El API de Storage de Phonegap, que es básicamente WebSQL, tiene una serie de limitaciones:

• Espacio: no hay un comportamiento consistente, pero se habla de límites tan bajos como 5mb.
• Persistencia: en algunas versiones de iOS hay bugs que hacen que el WebSQL de [el equivalente de] un WebView se almacene en una carpeta temporal sin garantía de que persista.
• Carga inicial: no hay ningún API para inyectar los datos directamente como un fichero SQLite, sino que hay que hacerlo (como hemos hecho hasta ahora) a mano, en el código JavaScript.

Una alternativa que elimina estos tres problemas es usar algún plugin que exponga en PhoneGap un API JavaScript para manipular directamente un SQLite nativo del dispositivo. Cosas a tener en cuenta:

• El plugin tiene que estar disponible para las plataformas objetivo.
• Se ha de "ensamblar" el API que este plugin exponga con el plugin de persistencia WebSQL que estábamos usando hasta el momento. Esto implica modificar o forkear persistence.store.websql.js.
• La configuración en desarrollo vs. producción cambia por completo. Para depurar en un navegador hará falta mockear la base de datos de manera distinta.
• La generación de datos desde el catálogo debe ser en formato SQLite. Quizás sea conveniente mantener un volcado a json para desarrollo.

De momento, el plugin que parece más interesante es https://github.com/pgsqlite.

[jrvidal]

No es una solución, pero quizá es interesante mencionarlo: http://html5sql.com/ Carga una lista de SQL statements desde javascript, supuestamente con buen rendimiento.

[jrvidal]

He sido capaz de hacer funcionar pgsqlite para que cargue una BDD SQLite.

Esta funcionalidad no la trae por defecto el plugin, sino que hay que añadir algo de código a mano. Existe un fork (un poco anticuado) donde implementan esto para Android, y explican de dónde sacan el código (que incluye iOS también).

[jrvidal]

Relacionado con #9.

Para seguir usando persistence.js [1], necesitamos adaptar nuestro esquema de volcado de la BDD sqlite a la estructura que esta librería monta cuando persiste entidades.

En particular, todas las entidades tienen que tener una clave primaria id de tipo VARCHAR(32). Adjunto un log del SQL que se ejecuta al definir una nueva entidad:

CREATE TABLE IF NOT EXISTS `Foo` (`foobar` TEXT, `id` VARCHAR(32) PRIMARY KEY) 

Por cierto, que esto supone acoplarnos al funcionamiento interno de la librería. :confused:

[ehdez73]

Adaptar el id a VARCHAR(32) no es problema.

Por un lado se podría guardar el id del objeto tal cual ya que el ObjectId de Mongo tiene una longitud inferior. pero a la hora de realizar los test de exportación se utiliza UUID para generar los id de forma aleatoria (no se utiliza Mongo), y es aquí donde tiene una longitud superior.

Para que funcione en los dos casos se puede exportar el campo id del Poi como "idPoi" y añado un campo "id" nuevo para la base de datos con valores autoincrementales. De esta forma se desacoplaría el id de la tabla SQLite con el id de MongoDB

Habrá que ver si realmente hará falta el campo idPoi , en caso contrario se puede eliminar.

[jrvidal]

• [x] Ojo, tiene que haber un id para cada entidad. Ahora mismo no se genera un id para los Tags, por ejemplo.

• [x] Puestos a pedir, ya que el json se va a generar sólo para probar en desarrollo, sería bueno prescindir de la estructura típica de objetos anidados:

  created: 100,
  location: {
    lat: ... ,
    lng: ...
  }

  y que se exporte como una lista de campos sin niveles:

  created: 100,
  lat: ... ,
  lng: ...

• [ ] Para desarrollo, creo que sería mejor tener unos datos de prueba extensos, de unos 200 POI, y con todos los campos rellenos. Si te parece OK, lo puedo hacer yo perfectamente.

[ehdez73]

El test está hecho para comprobar que se exporta correctamente, no está ideado para exportar una gran cantidad de datos. Puedes generar esa exportación usando la propia aplicación web, para ello ejecuta previamente la clase MongoDbPopulator.java ( que la puedes configurar con el número de POIs que quieres ) y despliega la aplicación en el tcServer que viene integrado con el STS. Accede a http://localhost:8080/opencatalog/admin/exporter