Cela ressemble beaucoup à un problème de transaction, où vous n'êtes pas COMMIT ting vos transactions après que vous travailliez, de sorte que les modifications sont perdues. Si votre pilote SQLite est par défaut COMMIT ting transactions qui sont fermées sans un COMMIT explicite ou rollback, et votre pilote Pg par défaut est ROLLBACK , vous obtiendrez le comportement décrit. La même chose se produira si le SQLite par défaut exécute automatiquement chaque instruction par défaut et que le pilote du pilote Pg ouvre par défaut une transaction.
C'est l'une des nombreuses bonnes raisons d'utiliser la même base de données locale pour les tests que celle sur laquelle vous allez déployer lorsque vous souhaitez mettre en service.
Si vous étiez sur une instance Pg normale, je vous dirais d'activer log_statement = 'all' dans postgresql.conf , rechargez Pg et regardez les journaux. Vous ne pouvez pas faire cela sur Heroku, mais vous avez accès aux journaux Pg avec heroku logs --ps postgres . Essayez d'exécuter ALTER USER my_heroku_user SET log_statement = 'all'; , retester et examiner les journaux.
Sinon, installez Pg localement.
Autres possibilités moins probables qui me viennent à l'esprit :
- Vous utilisez des transactions SERIALIZABLE de longue durée pour les lectures, de sorte que leur instantané n'est jamais mis à jour. Plutôt improbable.
- Les autorisations sur les objets de la base de données provoquent
INSERTs,UPDATEs, etc échouent et votre application ignore les erreurs qui en résultent. Encore une fois, peu probable. - Vous avez
DO INSTEADrègles qui ne font pas ce que vous attendez, ouBEFOREdéclencheurs qui renvoientNULL, transformant ainsi silencieusement les opérations en opérations nulles. Cela semble peu probable si vous testez avec SQLite. - Vous écrivez dans une base de données différente de celle à partir de laquelle vous lisez. Pas impossible dans les configurations qui tentent de lire à partir d'un cluster de serveurs de secours, etc.
