Das klingt sehr nach einem Transaktionsproblem, bei dem Sie nicht COMMIT sind Ändern Sie Ihre Transaktionen nach der Arbeit, sodass die Änderungen verloren gehen. Wenn Ihr SQLite-Treiber standardmäßig auf COMMIT eingestellt ist ting-Transaktionen, die ohne explizites COMMIT geschlossen wurden oder Rollback, und Ihr Pg-Treiber ist standardmäßig auf ROLLBACK eingestellt , würden Sie das beschriebene Verhalten erhalten. Dasselbe passiert, wenn SQLite standardmäßig jede Anweisung automatisch festschreibt und der Pg-Treiber standardmäßig eine Transaktion öffnet.
Dies ist einer der vielen guten Gründe, dieselbe lokale Datenbank zum Testen zu verwenden, in der Sie bereitstellen werden, wenn Sie live gehen möchten.
Wenn Sie sich auf einer normalen Pg-Instanz befinden, würde ich Ihnen sagen, dass Sie log_statement = 'all' aktivieren sollen in postgresql.conf , laden Sie Pg neu und beobachten Sie die Protokolle. Auf Heroku ist das nicht möglich, aber Sie haben Zugriff auf die Pg-Protokolle mit heroku logs --ps postgres . Versuchen Sie, ALTER USER my_heroku_user SET log_statement = 'all'; auszuführen , erneutes Testen und Untersuchen der Protokolle.
Alternativ können Sie Pg lokal installieren.
Andere weniger wahrscheinliche Möglichkeiten, die mir einfallen:
- Sie verwenden SERIALIZABLE-Transaktionen mit langer Laufzeit für Lesevorgänge, sodass deren Snapshot nie aktualisiert wird. Ziemlich unwahrscheinlich.
- Berechtigungen für Datenbankobjekte verursachen
INSERTs,UPDATEs usw. fehlschlagen und Ihre App ignoriert die resultierenden Fehler. Wiederum unwahrscheinlich. - Sie haben
DO INSTEADRegeln, die nicht das tun, was Sie erwarten, oderBEFORETrigger, dieNULLzurückgeben , wodurch Operationen stillschweigend in No-Ops umgewandelt werden. Scheint unwahrscheinlich, wenn Sie mit SQLite testen. - Sie schreiben in eine andere Datenbank als Sie lesen. Nicht unmöglich in Setups, die versuchen, aus einem Cluster von Hot-Standbys usw. zu lesen.
