Problème de migration : impossible de supprimer la fonction delete_user_password() car d'autres objets en dépendent

Soutien
1 
PG::DependentObjectsStillExist: ERROR:  cannot drop function delete_user_password() because other objects depend on it

Semble provenir d’ici :

2

C’est une migration post :


== 20240910090759 MakePasswordColumnsFromUsersReadOnly: migration =============
-- execute("DROP TRIGGER IF EXISTS users_password_sync_on_delete_password ON users;\n")
   -> 0.0007s
-- execute("DROP FUNCTION IF EXISTS delete_user_password;\n")
rake avorté !
StandardError : Une erreur s'est produite, celle-ci et toutes les migrations ultérieures sont annulées : (StandardError)

PG::DependentObjectsStillExist : ERREUR :  impossible de supprimer la fonction delete_user_password() car d'autres objets en dépendent
DETAIL :  le déclencheur users_password_sync_on_delete_password sur la table backup.users dépend de la fonction delete_user_password()
HINT :  Utilisez DROP ... CASCADE pour supprimer également les objets dépendants.
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rack-mini-profiler-4.0.0/lib/patches/db/pg/alias_method.rb:109:in `exec'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rack-mini-profiler-4.0.0/lib/patches/db/pg/alias_method.rb:109:in `async_exec'
(eval at /var/www/discourse/lib/method_profiler.rb:38):24:in `async_exec'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activerecord-7.2.2.1/lib/active_record/connection_adapters/postgresql/database_statements.rb:56:in `block (2 levels) in raw_execute'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activerecord-7.2.2.1/lib/active_record/connection_adapters/abstract_adapter.rb:1004:in `block in with_raw_connection'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-7.2.2.1/lib/active_support/concurrency/null_lock.rb:9:in `synchronize'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activerecord-7.2.2.1/lib/active_record/connection_adapters/abstract_adapter.rb:976:in `with_raw_connection'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activerecord-7.2.2.1/lib/active_record/connection_adapters/postgresql/database_statements.rb:55:in `block in raw_execute'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-7.2.2.1/lib/active_support/notifications/instrumenter.rb:58:in `instrument'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activerecord-7.2.2.1/lib/active_record/connection_adapters/abstract_adapter.rb:1119:in `log'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activerecord-7.2.2.1/lib/active_record/connection_adapters/postgresql/database_statements.rb:54:in `raw_execute'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activerecord-7.2.2.1/lib/active_record/connection_adapters/abstract/database_statements.rb:538:in `internal_execute'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activerecord-7.2.2.1/lib/active_record/connection_adapters/abstract/database_statements.rb:137:in `execute'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activerecord-7.2.2.1/lib/active_record/connection_adapters/abstract/query_cache.rb:27:in `execute'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activerecord-7.2.2.1/lib/active_record/connection_adapters/postgresql/database_statements.rb:48:in `execute'
1 « J'aime »
3

Vous avez des tables dans le schéma backup (utilisé lors des sauvegardes/restaurations) qui dépendent de cette fonction.

Le schéma backup est-il obsolète ici ? Si c’est le cas, vous n’avez probablement besoin que de DROP SCHEMA backup ici pour vous en débarrasser.

1 « J'aime »
4

Merci beaucoup ! Cela semble correct, mais quand je fais ça, j’obtiens des choses comme :slight_smile:

table backup.group_archived_messages depends on schema backup
table backup.incoming_emails depends on schema backup
table backup.user_options depends on schema backup
table backup.email_change_requests depends on schema backup
table backup.given_daily_likes depends on schema backup
table backup.onceoff_logs depends on schema backup
table backup.tags depends on schema backup
table backup.topic_tags depends on schema backup
table backup.tag_users depends on schema backup
table backup.category_tags depends on schema backup
table backup.scheduler_stats depends on schema backup
table backup.tag_groups depends on schema backup

C’était une base de données fraîche/vide quand j’ai commencé, donc je suis confus pourquoi j’ai une base de données de sauvegarde obsolète.

EDIT : J’ai utilisé cascade, comme cela m’a été indiqué :

DROP SCHEMA backup CASCADE;

Je suppose que cela a résolu le problème ! Il faudra 25 minutes avant que je le sache et j’espère que j’aurai arrêté de regarder un ordinateur d’ici là.

Je vous tiendrai au courant demain.

Merci encore.

1 « J'aime »
5

C’était ça. Je suis sûr à 99 % d’avoir arrêté une restauration avec control-c pour une raison quelconque (comme le fait qu’elle prenne 25 minutes) et que cela ait laissé derrière le schéma obsolète. Je n’arrive pas à croire que ce ne soit pas quelque chose que j’ai réussi à apprendre au cours de la dernière décennie, mais c’est ainsi !

Merci beaucoup.

1 « J'aime »
6

Ce sujet a été automatiquement fermé 30 jours après la dernière réponse. Les nouvelles réponses ne sont plus autorisées.