android - transact - trigger sqlite ejemplo

SQLite: ¿Cómo limitar el número de filas según la marca de tiempo?

Question

Utilicé con éxito el siguiente desencadenante BEFORE INSERT para limitar el número de filas almacenadas en las ubicaciones de la tabla de la base de datos SQLite. La tabla de la base de datos actúa como un caché en una aplicación de Android.

CREATE TRIGGER ''trigger_locations_insert''
BEFORE INSERT ON ''locations''
WHEN ( SELECT count(*) FROM ''locations'' ) > ''100''
BEGIN
DELETE FROM ''locations'' WHERE ''_id'' NOT IN
(
SELECT ''_id'' FROM ''locations'' ORDER BY ''modified_at'' DESC LIMIT ''100''
);
END

Mientras tanto, agregué un segundo disparador que me permite INSERT OR UPDATE filas. - La discusión sobre ese tema se puede encontrar en otro hilo . El segundo activador requiere una VIEW en la que se ejecuta cada INSERT .

CREATE VIEW ''locations_view'' AS SELECT * FROM ''locations'';

Como un INSERT ya no se ejecuta en las ubicaciones TABLE pero en la vista VIEW locations_ , el desencadenante anterior ya no funciona. Si aplico el disparador en la vista, se lanza el siguiente mensaje de error.

Failure 1 (cannot create BEFORE trigger on view: main.locations_view)

Pregunta:

¿Cómo puedo cambiar el disparador anterior para observar cada INSERT en la VIEW ? ¿O me recomiendan otra forma de limitar el número de filas? Preferiría manejar este tipo de operación dentro de la base de datos, en lugar de ejecutar código frontend en mi cliente.

Problemas de desempeño:

Aunque, el limitador (el disparador anterior) funciona en general: ¡funciona menos que lo óptimo! En realidad, las acciones de la base de datos tardan tanto que se genera un ANR. Por lo que puedo ver, la razón es que se llama al limitador cada vez que ocurre un INSERT . Para optimizar la configuración, el INSERT granel debe ser envuelto en una transacción y el limitador debe funcionar inmediatamente después. es posible? Si desea ayudar, haga los comentarios de optimización sobre INSERT granel en la pregunta original . Los comentarios sobre el limitador son bienvenidos aquí.

Answer 1

Este tipo de disparador debería funcionar bien junto con el otro. El problema parece ser que el SQL cita innecesariamente el campo _id . Está seleccionando la cadena literal "_id" para cada fila y comparándola con la misma cadena literal.

Quitar las comillas alrededor de ''_id'' (tanto en el DELETE como en el sub SELECT ) debería solucionar el problema.