Fehlgeschlagenes Upgrade: UniqueViolation: doppelter Schlüsselwert verletzt eindeutige Beschränkung "data_explorer_queries_pkey"

Das heutige Upgrade auf die neueste Version ist fehlgeschlagen:

FAILED
--------------------
Pups::ExecError: cd /var/www/discourse && su discourse -c 'bundle exec rake db:migrate' fehlgeschlagen mit Rückgabewert #<Process::Status: pid 3194 exit 1>
Ort des Fehlers: /pups/lib/pups/exec_command.rb:112:in `spawn'
Ausführen fehlgeschlagen mit den Parametern {"cd"=>"$home", "hook"=>"db_migrate", "cmd"=>["su discourse -c 'bundle exec rake db:migrate'"]}
590cf0611c566ea6df5f70ffdd2cec2359e84eaea29b7abcde77d56288a46370
** BOOTSTRAP FEHLGESCHLAGEN ** Bitte scrollen Sie nach oben und suchen Sie nach früheren Fehlermeldungen; es kann mehr als eine geben.

Im Log oben:

Verursacht durch:
PG::UniqueViolation: ERROR:  duplicate key value violates unique constraint "data_explorer_queries_pkey"
DETAIL:  Key (id)=(-10) already exists.

und

rake aborted!
StandardError: Ein Fehler ist aufgetreten, diese und alle folgenden Migrationen wurden abgebrochen:

ERROR:  duplicate key value violates unique constraint "data_explorer_queries_pkey"
DETAIL:  Key (id)=(-10) already exists.

Also muss ich wohl den doppelten Schlüssel data_explorer_queries_pkey entfernen.

Wie mache ich das?

1 „Gefällt mir“
3 „Gefällt mir“

Danke, aber ich komme nicht in die App:

./launcher enter app
Fehlerantwort vom Daemon: Container 694b24a2a235e90456fb0ca770c86ac14bb914ad33ada8a18fc4777a1188d848 läuft nicht
root@gaoa-discourse:/var/discourse#

Und außerdem:

root@gaoa-discourse:/var/discourse# su - postgres
Kein Passworteintrag für Benutzer 'postgres'
1 „Gefällt mir“

Also den Container neu starten?

./launcher start app

Dann möchtest du so etwas wie:

./launcher enter app

dann:

su postgres -c 'psql discourse'

4 „Gefällt mir“

Danke! Ich bin mir nicht sicher, warum es beim ersten Versuch nicht gestartet hat.

Es sieht so aus, als hätte ich eine doppelte ID “10”:

4374 | discourse-data-explorer | q:-10 | JSON      | {"id":-10,"name":"Inactive Users with no posts","description":"analyze pre-Discourse signups.","sql":"SELECT\
n    u.id,\n    u.username_lower AS \"username\",\n    u.created_at,\n    u.last_seen_at\nFROM users u\nWHERE u.active = false\nORDER BY u.id\n","created_by":"-1",
"created_at":null,"group_ids":[],"last_run_at":"2019-10-21T04:03:35.548+00:00"}

4114 | discourse-data-explorer | q:-10 | JSON      | {"id":-10,"name":"Inactive Users with no posts","description":"analyze pre-Discourse signups.","sql":"SELECT\
n    u.id,\n    u.username_lower AS \"username\",\n    u.created_at,\n    u.last_seen_at\nFROM users u\nWHERE u.active = false\nORDER BY u.id\n","created_by":"-1",
"created_at":null,"last_run_at":"2019-02-27T06:17:48.317+00:00"}

Also sollte ich wohl folgendes ausführen:

DELETE from plugin_store_rows WHERE id = 10

oder sollte es sein:

DELETE from plugin_store_rows WHERE id = -10

Ich bin neugierig – welcher Eintrag wird durch den obigen Befehl gelöscht – der erste, der gefunden wird, oder beide?

1 „Gefällt mir“

Die Nummern in der ID-Spalte sind 4374 und 4114. Löschen Sie diejenige mit der höchsten Nummer.

Führen Sie NICHT DELETE from plugin_store_rows WHERE id = 10 aus!! Sonst löschen Sie den falschen Eintrag!

3 „Gefällt mir“

Ah, also das hier?

DELETE from plugin_store_rows WHERE id = 4374;

1 „Gefällt mir“

Ja. Du solltest doch den richtigen Spaltenüberschrift in der PL/SQL-Abfrageausgabe sehen, oder?

1 „Gefällt mir“

Wenn du das erwähnst, ja. Ich habe nach unten gescrollt, weil die Ausgabe so aussieht:

2 „Gefällt mir“

Ja, generell solltest du Befehle vor dem Commit ausführen, um ihre Auswirkungen zu prüfen, siehe:

Wenn du dann feststellst, dass du 500 Zeilen gelöscht hast, obwohl du nur eine treffen wolltest, hast du die Möglichkeit, das ohne Bedenken zurückzusetzen.

3 „Gefällt mir“

Erfolg! :tada: Danke für die Anleitung @merefield.

Meinem DELETE-Befehl fehlte ein abschließendes Semikolon (oben aktualisiert).

3 „Gefällt mir“

Oh ja, das passiert mir jedes Mal :wink:

3 „Gefällt mir“

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.