Brzmi to jak problem z transakcją, w którym nie jesteś COMMIT transakcji po zakończeniu pracy, więc zmiany zostaną utracone. Jeśli twój sterownik SQLite domyślnie to COMMIT transakcji, które są zamykane bez wyraźnego COMMIT lub wycofaj, a twój sterownik Pg domyślnie to ROLLBACK , otrzymasz opisane zachowanie. To samo stanie się, jeśli SQLite domyślnie automatycznie uruchamia każdą instrukcję, a sterownik sterownika Pg domyślnie otwiera transakcję.
Jest to jeden z wielu dobrych powodów, aby używać tej samej lokalnej bazy danych do testowania, w której zamierzasz wdrożyć, gdy chcesz rozpocząć działanie.
Gdybyś był na normalnej instancji Pg, powiedziałbym ci, aby włączyć log_statement = 'all' w postgresql.conf , załaduj ponownie Pg i obserwuj dzienniki. Nie możesz tego zrobić w Heroku, ale masz dostęp do dzienników Pg za pomocą heroku logs --ps postgres . Spróbuj uruchomić ALTER USER my_heroku_user SET log_statement = 'all'; , ponowne testowanie i sprawdzanie dzienników.
Alternatywnie zainstaluj Pg lokalnie.
Inne mniej prawdopodobne możliwości, które przychodzą mi do głowy:
- Do odczytów używasz długotrwałych transakcji SERIALIZABLE, więc ich migawka nigdy nie jest aktualizowana. Całkiem mało prawdopodobne.
- Uprawnienia do obiektów bazy danych powodują
INSERTs,UPDATEs itp., aby zakończyć się niepowodzeniem, a aplikacja ignoruje powstałe błędy. Znowu mało prawdopodobne. - Masz
DO INSTEADreguły, które nie robią tego, czego oczekujesz, lubBEFOREwyzwalacze zwracająceNULL, w ten sposób po cichu zamieniając operacje w no-ops. Wydaje się mało prawdopodobne, jeśli testujesz z SQLite. - Piszesz do innej bazy danych niż czytasz. Nie jest to niemożliwe w konfiguracjach, które próbują czytać z klastra gorących rezerw itp.
