Esto se parece mucho a un problema de transacción, en el que no estás COMMIT ting sus transacciones después de hacer el trabajo, por lo que los cambios se pierden. Si su controlador SQLite está predeterminado en COMMIT transacciones que se cierran sin un COMMIT explícito o retroceder, y su controlador Pg tiene como valor predeterminado ROLLBACK , obtendrá el comportamiento descrito. Lo mismo sucederá si el SQLite tiene como opción predeterminada la confirmación automática de cada declaración y el controlador del controlador Pg tiene como opción predeterminada la apertura de una transacción.
Esta es una de las muchas buenas razones para usar la misma base de datos local para realizar pruebas que la que va a implementar cuando quiera ponerlo en marcha.
Si estuviera en una instancia de Pg normal, le diría que habilite log_statement = 'all' en postgresql.conf , recargar Pg y ver los registros. No puede hacer eso en Heroku, pero tiene acceso a los registros de Pg con heroku logs --ps postgres . Intente ejecutar ALTER USER my_heroku_user SET log_statement = 'all'; , volver a probar y examinar los registros.
Alternativamente, instale Pg localmente.
Otras posibilidades menos probables que se me ocurren:
- Está utilizando transacciones SERIALIZABLES de ejecución prolongada para las lecturas, por lo que su instantánea nunca se actualiza. Bastante improbable.
- Los permisos en los objetos de la base de datos están causando
INSERTs,UPDATEs, etc. para fallar, y su aplicación ignora los errores resultantes. De nuevo, poco probable. - Tienes
DO INSTEADreglas que no hacen lo que esperas, oBEFOREactivadores que devuelvenNULL, convirtiendo así silenciosamente las operaciones en no-ops. Parece poco probable si está probando con SQLite. - Está escribiendo en una base de datos diferente de la que está leyendo. No es imposible en configuraciones que intentan leer desde un grupo de hot standby, etc.
