Това звучи много като проблем с транзакция, при който не сте COMMIT след като свършите работа, промените се губят. Ако вашият SQLite драйвер по подразбиране е COMMIT ting транзакции, които са затворени без изричен COMMIT или връщане назад и вашият драйвер за Pg по подразбиране е ROLLBACK , ще получите описаното поведение. Същото ще се случи, ако SQLite по подразбиране автоматично изпраща всеки израз по подразбиране, а драйверът на Pg драйвера по подразбиране отваря транзакция.
Това е една от многото добри причини да използвате същата локална база данни за тестване, в която ще внедрявате, когато искате да стартирате на живо.
Ако бяхте на нормален екземпляр на Pg, бих ви казал да активирате log_statement = 'all' в postgresql.conf , презаредете Pg и гледайте регистрационните файлове. Не можете да направите това на Heroku, но имате достъп до регистрационните файлове на Pg с heroku logs --ps postgres . Опитайте да изпълните ALTER USER my_heroku_user SET log_statement = 'all'; , повторно тестване и преглед на регистрационните файлове.
Алтернативно, инсталирайте Pg локално.
Други по-малко вероятни възможности, които идват на ум:
- Използвате дълготрайни SERIALIZABLE транзакции за четения, така че тяхната моментна снимка никога не се актуализира. Доста малко вероятно.
- Разрешенията за обекти на база данни причиняват
INSERTs,UPDATEs и т.н. да се провали и приложението ви игнорира произтичащите грешки. Отново, малко вероятно. - Имате
DO INSTEADправила, които не правят това, което очаквате, илиBEFOREтригери, които връщатNULL, като по този начин безшумно превръща операциите в no-ops. Изглежда малко вероятно, ако тествате с SQLite. - Вие пишете в база данни, различна от тази, от която четете. Не е невъзможно при настройки, които се опитват да четат от клъстер от горещи режими на готовност и т.н.
