LQPP/Datenbankeingriffe

Aus Piratenwiki
Wechseln zu: Navigation, Suche

Inhaltsverzeichnis

LOG für Datenbankeingriffe auf lqfb.piratenpartei.de

Die Eingriffe beziehen sich auch die PostgrSQL Datenbank mit dem Namen 'liquid_feedback' (vor dem Upgrade auf LiquidFeedback 'liquid_feedback_pp').


2013-10-04 ~23:42 (ib) - Einfrieren der Themen zum Bundesparteitag

Wie schon in der Vergangenheit, werden die Themen zum kommenden Bundesparteitag manuell eingefroren und die Zeiten angepasst, damit die Abstimmungen vor Ende der Antragsfrist abgeschlossen sind. Mehr Informationen gibt es im Vorstandsportal. 

BEGIN;

  UPDATE issue
  SET
    state = 'verification',
    half_frozen = '2013-10-04 23:42',
    verification_time = '7 days',
    voting_time = '14 days'
  WHERE
    policy_id in (1,2) AND ( 
      ( state = 'discussion'   AND accepted    < '2013-10-01 23:43' ) OR 
      ( state = 'verification' AND half_frozen > '2013-09-25 23:42' ) 
    );

COMMIT;

BEGIN
UPDATE 11
COMMIT


2013-08-23 ~09:00 (ib) - Sperren von Accounts

Von der Clearingstelle wurden 14 Codes zum Sperren übermittelt. Im folgenden werden die dazugehörigen existierenden Accounts gesperrt und nicht verwendete Einladungscodes gelöscht: 

BEGIN ;
  UPDATE member
    SET 
      locked = TRUE,
      active = FALSE,
      admin_comment = 'Locked on 2013-08-23'
    WHERE
      invite_code in 
        (
           'xxxxx-xxxxxx-xxxxx-xxxxx', 'xxxxx-xxxxx-xxxxx-xxxxx-xxxxx', ...
        );

  DELETE FROM member
    WHERE
      activated isnull 
      AND invite_code in 
        (
           'xxxxx-xxxxxx-xxxxx-xxxxx', 'xxxxx-xxxxx-xxxxx-xxxxx-xxxxx', ...
        );
END ;

BEGIN
UPDATE 14
DELETE 12
COMMIT

Betroffene Nutzer werden per E-Mail informiert.


2013-05-22 ~14:20 (ib) - Entfernen von Teilnehmerdaten

In der Datenbank befinden sich noch unvollständige Teilnehmerdaten von Konten die vor langer Zeit gesperrt wurden: 

SELECT id FROM member WHERE locked=TRUE AND admin_comment ISNULL AND password NOTNULL AND last_login < '2012-09-01' ;

(1887 rows)

Nach einer Sichtkontrolle der ausgewählten Accounts werden die Daten gelöscht. 

BEGIN;
SELECT delete_member( xxx ) ;
[...]
SELECT delete_member( xxx ) ;
COMMIT;

1887 x (1 row)

2013-05-22 ~14:00 (ib) - Entfernen von Teilnehmerdaten

Die Teilnehmerdaten von allen Konten die vor dem 20.5. gesperrt wurden, sollen aus Datenschutzgründen aus der Datenbank entfernt werden: 

SELECT id FROM member WHERE locked=TRUE AND admin_comment <> 'Teilnehmerkreis 2013-05-20' ;

(604 rows)

Nach einer Sichtkontrolle der ausgewählten Accounts werden die Daten gelöscht. 

BEGIN;
SELECT delete_member( xxx ) ;
[...]
SELECT delete_member( xxx ) ;
COMMIT;

604 x (1 row)

2013-05-20 ~23:00 (ib) - Gebietsgliederungen

In Zukunft haben Landesverbände die Möglichkeit, einen Gliederungsbereich im bundesweiten System zu verwenden. Heute wurde im Rahmen eines Pilotversuchs der Bereich für Schleswig-Hollstein aktiviert. 

BEGIN;

UPDATE unit
  set description = 'Bundesverband der Piratenpartei Deutschland'
where
  name = 'Bundesebene'
;

INSERT INTO unit
  (id, parent_id, active, name, description)
VALUES
  (2, 1, TRUE, 'Schleswig-Holstein', 'Landesverband Schleswig-Holstein')
;

INSERT INTO area
  (id, unit_id, name, description)
VALUES
  (201, 2, '[SH] Sandkasten/Spielwiese', 'Der Themenbereich Sandkasten/Spielwiese ist zum Ausprobieren und Spaßhaben gedacht. Wer will kann sich gerne zum Obst machen. I
  (202, 2, '[SH] Innerparteiliche Angelegenheiten', 'In diesen Bereich gehören alle Themen die sich nicht mit politischen Inhalten beschäftigen.'),
  (203, 2, '[SH] Politische Themen', 'In diesen Bereich gehören alle politischen Themen.')
;

INSERT INTO allowed_policy
  (area_id, policy_id, default_policy)
VALUES
  (201, 1, FALSE),
  (201, 2, FALSE),
  (201, 4, TRUE),
  (201, 5, FALSE),
  (202, 1, FALSE),
  (202, 4, TRUE),
  (202, 5, FALSE),
  (203, 2, FALSE),
  (203, 4, TRUE),
  (203, 5, FALSE)
;

COMMIT; 

BEGIN
UPDATE 1
INSERT 0 1
INSERT 0 3
INSERT 0 10
COMMIT



BEGIN;

INSERT INTO privilege
    (unit_id, member_id)
VALUES
    (2, xxx),
    ...
    (2, xxx),
;

COMMIT;

BEGIN
INSERT 0 288
COMMIT


2013-05-20 ~02:00 (ib) - Teilnehmerkreisprüfung

Von der Mitgliederverwaltung wurden über die Clearingstelle Listen der gültigen Einladungscodes und der stimmberechtigten Accounts übermittelt.

Bisher unbenutzte Invitecodes und laut Mitgliederverwaltung ungültige Einladungscodes wurden entfernt. 

delete from member
where
  activated isnull and
  invite_code not in (
    'xxxxx-xxxxx-xxxxx', 'xxxxx-xxxxx-xxxxx-xxxxx', ...
  );

DELETE 2144

Genutzte ungültige Konten wurden gesperrt und inaktiviert. Der Großteil (852) dieser Accounts war bereits inaktiv. 

UPDATE member
  set locked = TRUE , 
      active = FALSE , 
      admin_comment = 'Teilnehmerkreis 2013-05-20'
WHERE
  locked = FALSE AND
  invite_code NOT IN (
    'xxxxx-xxxxx-xxxxx', 'xxxxx-xxxxx-xxxxx-xxxxx', ...
  );

BEGIN
UPDATE 1061
COMMIT

Die gesperrten Teilnehmer wurden per E-Mail benachrichtigt.


2013-03-17 ~20:00 (ib) - Entfrieren eines manuell eingefrorenen Themas

Dieses Thema wurde am 10.03. manuell eingefroren und dadurch um seine Diskussionsphase gebracht. In Rücksprache mit den Antragsstellern der einzigen Initiative, der Antragskommission und dem Buvo wird es wieder in die Diskussionsphase versetzt. Der normale Zyklus wird vor dem BPT durch sein. 

BEGIN;
  UPDATE issue
  SET
    state = 'discussion',
    half_frozen = NULL,
    verification_time = '15 days',
    voting_time = '15 days'
  WHERE
    policy_id = 2 AND
    state = 'verification' AND
    id = 3248 ;
COMMIT;

BEGIN
UPDATE 1
COMMIT

Notiz: Das manuelle Einfrieren sollte in Zukunft wieder wie in der Vergangenheit gehandhabt werden. D.h. die Diskussionsphase endet kurz vor der Antragsfrist und die Abstimmungen enden kurz vor dem Parteitag. Dadurch wird keine Initiative die sowieso rechtzeitig geendet hätte verkürzt. Außerdem ist es dann so lange wie möglich möglich, neue Themen einzustellen, die noch vor dem BPT durch sind. Es gibt keinen triftigen Grund, warum die Abstimmungen schon vor der Antragsfrist abgeschlossen seinen müssen.

2013-03-15 ~23:00 (ib) - Manuelles Verifizieren einer E-Mail-Adresse

Der Nutzer hat einen Code erhalten und diesen bestätigt. 

BEGIN;
UPDATE member
  SET notify_email = notify_email_unconfirmed, 
      notify_email_unconfirmed = NULL ,
      notify_email_secret = NULL,
      notify_email_secret_expiry = NULL,
      notify_email_lock_expiry = NULL
  WHERE id = XXX ;
select id,name,notify_email,notify_email_unconfirmed,notify_email_secret,notify_email_secret_expiry,notify_email_lock_expiry from member where id = XXX ;
COMMIT;

BEGIN
UPDATE 1
???
COMMIT

2013-03-10 ~23:42 (ib) - Einfrieren der Themen zum Bundesparteitag

Wie schon in der Vergangenheit, werden die Themen zum kommenden Bundesparteitag manuell eingefroren und die Zeiten angepasst, damit die Abstimmungen vor Ende der Antragsfrist abgeschlossen sind. Mehr Informationen gibt es im Vorstandsportal. 

BEGIN;
  UPDATE issue
  SET
    state = 'verification',
    half_frozen = '2013-03-10 23:42',
    verification_time = '7 days',
    voting_time = '14 days'
  WHERE
    policy_id in (1,2) AND ( 
      ( state = 'discussion'   AND accepted    < '2013-03-07 23:43' ) OR 
      ( state = 'verification' AND half_frozen > '2013-03-02 23:42' ) 
    );
    ;
COMMIT;

BEGIN
UPDATE 68
COMMIT

Folgende Themen sind betroffen: 3125, 3131, 3132, 3133, 3134, 3135, 3175, 3180, 3181, 3183, 3185, 3215, 3216, 3219, 3220, 3222, 3223, 3233, 3234, 3242, 3243, 3248, 3249, 3250, 3251, 3252, 3253, 3254, 3255, 3256, 3257, 3258, 3272, 3273, 3276, 3277, 3282, 3283, 3285, 3286, 3288, 3292, 3293, 3296, 3298, 3299, 3300, 3301, 3304, 3305, 3307, 3308, 3309, 3310, 3315, 3317, 3318, 3319, 3320, 3321, 3322, 3323, 3325, 3327, 3328, 3329, 3335, 3338.


2013-02-20 ~19:00 (ib) - Änderung des Lockings

Hiermit wird der in diesem Ticket empfohlene Patch eingespielt. Dadurch soll der Hintergrundprozess (Auszählungen etc.) schneller laufen und Locking-Fehler zu reduziert werden.

BEGIN; 

CREATE OR REPLACE FUNCTION "create_interest_snapshot"
  ( "issue_id_p" "issue"."id"%TYPE )
  RETURNS VOID
  LANGUAGE 'plpgsql' VOLATILE AS $$
    DECLARE
      "member_id_v" "member"."id"%TYPE;
    BEGIN
      DELETE FROM "direct_interest_snapshot"
        WHERE "issue_id" = "issue_id_p"
        AND "event" = 'periodic';
      DELETE FROM "delegating_interest_snapshot"
        WHERE "issue_id" = "issue_id_p"
        AND "event" = 'periodic';
      DELETE FROM "direct_supporter_snapshot"
        USING "initiative"  -- NOTE: due to missing index on issue_id
        WHERE "initiative"."issue_id" = "issue_id_p"
        AND "direct_supporter_snapshot"."initiative_id" = "initiative"."id"
        AND "direct_supporter_snapshot"."event" = 'periodic';
      INSERT INTO "direct_interest_snapshot"
        ("issue_id", "event", "member_id")
        SELECT
          "issue_id_p"  AS "issue_id",
          'periodic'    AS "event",
          "member"."id" AS "member_id"
        FROM "issue"
        JOIN "area" ON "issue"."area_id" = "area"."id"
        JOIN "interest" ON "issue"."id" = "interest"."issue_id"
        JOIN "member" ON "interest"."member_id" = "member"."id"
        JOIN "privilege"
          ON "privilege"."unit_id" = "area"."unit_id"
          AND "privilege"."member_id" = "member"."id"
        WHERE "issue"."id" = "issue_id_p"
        AND "member"."active" AND "privilege"."voting_right";
      FOR "member_id_v" IN
        SELECT "member_id" FROM "direct_interest_snapshot"
        WHERE "issue_id" = "issue_id_p"
        AND "event" = 'periodic'
      LOOP
        UPDATE "direct_interest_snapshot" SET
          "weight" = 1 +
            "weight_of_added_delegations_for_interest_snapshot"(
              "issue_id_p",
              "member_id_v",
              '{}'
            )
          WHERE "issue_id" = "issue_id_p"
          AND "event" = 'periodic'
          AND "member_id" = "member_id_v";
      END LOOP;
      INSERT INTO "direct_supporter_snapshot"
        ( "issue_id", "initiative_id", "event", "member_id",
          "draft_id", "informed", "satisfied" )
        SELECT
          "issue_id_p"            AS "issue_id",
          "initiative"."id"       AS "initiative_id",
          'periodic'              AS "event",
          "supporter"."member_id" AS "member_id",
          "supporter"."draft_id"  AS "draft_id",
          "supporter"."draft_id" = "current_draft"."id" AS "informed",
          NOT EXISTS (
            SELECT NULL FROM "critical_opinion"
            WHERE "initiative_id" = "initiative"."id"
            AND "member_id" = "supporter"."member_id"
          ) AS "satisfied"
        FROM "initiative"
        JOIN "supporter"
        ON "supporter"."initiative_id" = "initiative"."id"
        JOIN "current_draft"
        ON "initiative"."id" = "current_draft"."initiative_id"
        JOIN "direct_interest_snapshot"
        ON "supporter"."member_id" = "direct_interest_snapshot"."member_id"
        AND "initiative"."issue_id" = "direct_interest_snapshot"."issue_id"
        AND "event" = 'periodic'
        WHERE "initiative"."issue_id" = "issue_id_p";
      RETURN;
    END;
  $$;

CREATE OR REPLACE FUNCTION "set_snapshot_event"
  ( "issue_id_p" "issue"."id"%TYPE,
    "event_p" "snapshot_event" )
  RETURNS VOID
  LANGUAGE 'plpgsql' VOLATILE AS $$
    DECLARE
      "event_v" "issue"."latest_snapshot_event"%TYPE;
    BEGIN
      SELECT "latest_snapshot_event" INTO "event_v" FROM "issue"
        WHERE "id" = "issue_id_p" FOR UPDATE;
      UPDATE "issue" SET "latest_snapshot_event" = "event_p"
        WHERE "id" = "issue_id_p";
      UPDATE "direct_population_snapshot" SET "event" = "event_p"
        WHERE "issue_id" = "issue_id_p" AND "event" = "event_v";
      UPDATE "delegating_population_snapshot" SET "event" = "event_p"
        WHERE "issue_id" = "issue_id_p" AND "event" = "event_v";
      UPDATE "direct_interest_snapshot" SET "event" = "event_p"
        WHERE "issue_id" = "issue_id_p" AND "event" = "event_v";
      UPDATE "delegating_interest_snapshot" SET "event" = "event_p"
        WHERE "issue_id" = "issue_id_p" AND "event" = "event_v";
      UPDATE "direct_supporter_snapshot" SET "event" = "event_p"
        FROM "initiative"  -- NOTE: due to missing index on issue_id
        WHERE "initiative"."issue_id" = "issue_id_p"
        AND "direct_supporter_snapshot"."initiative_id" = "initiative"."id"
        AND "direct_supporter_snapshot"."event" = "event_v";
      RETURN;
    END;
  $$;
 
CREATE OR REPLACE FUNCTION "clean_issue"("issue_id_p" "issue"."id"%TYPE)
  RETURNS VOID
  LANGUAGE 'plpgsql' VOLATILE AS $$
    DECLARE
      "issue_row" "issue"%ROWTYPE;
    BEGIN
      SELECT * INTO "issue_row"
        FROM "issue" WHERE "id" = "issue_id_p"
        FOR UPDATE;
      IF "issue_row"."cleaned" ISNULL THEN
        UPDATE "issue" SET
          "state"           = 'voting',
          "closed"          = NULL,
          "ranks_available" = FALSE
          WHERE "id" = "issue_id_p";
        DELETE FROM "delegating_voter"
          WHERE "issue_id" = "issue_id_p";
        DELETE FROM "direct_voter"
          WHERE "issue_id" = "issue_id_p";
        DELETE FROM "delegating_interest_snapshot"
          WHERE "issue_id" = "issue_id_p";
        DELETE FROM "direct_interest_snapshot"
          WHERE "issue_id" = "issue_id_p";
        DELETE FROM "delegating_population_snapshot"
          WHERE "issue_id" = "issue_id_p";
        DELETE FROM "direct_population_snapshot"
          WHERE "issue_id" = "issue_id_p";
        DELETE FROM "non_voter"
          WHERE "issue_id" = "issue_id_p";
        DELETE FROM "delegation"
          WHERE "issue_id" = "issue_id_p";
        DELETE FROM "supporter"
          USING "initiative"
          WHERE "initiative"."issue_id" = "issue_id_p"
          AND "supporter"."initiative_id" = "initiative_id";
        UPDATE "issue" SET
          "state"           = "issue_row"."state",
          "closed"          = "issue_row"."closed",
          "ranks_available" = "issue_row"."ranks_available",
          "cleaned"         = now()
          WHERE "id" = "issue_id_p";
      END IF;
      RETURN;
    END;
  $$;

COMMIT;

BEGIN
psql:003-core-upgrade.sql:80: NOTICE:  type reference issue.id%TYPE converted to integer
CREATE FUNCTION
psql:003-core-upgrade.sql:110: NOTICE:  type reference issue.id%TYPE converted to integer
CREATE FUNCTION
psql:003-core-upgrade.sql:157: NOTICE:  type reference issue.id%TYPE converted to integer
CREATE FUNCTION
COMMIT


2013-02-17 ~23:00 (ib) - Einfrieren der Themen im Vorstandsbereich

Siehe 2012-11-04: 

BEGIN ;
  UPDATE issue 
    SET 
      half_frozen = '2013-02-17 17:00',
      state = 'verification' 
    WHERE 
      area_id in (12, 16) AND 
      policy_id = 11 AND 
      closed ISNULL AND 
      half_frozen ISNULL AND 
      accepted NOTNULL AND 
      accepted < '2013-02-16 17:00' ; 
COMMIT ;

BEGIN
UPDATE 1
COMMIT


2013-02-08 ~12:00 (ib) - Einfrieren des Themas zum BTW13-Design-Entwurf

Begründung: Das Ergebnis der Abstimmung soll vor der Deadline zum 23.2. vorliegen. Die Verkürzung Diskussions- und Verificationsphase wurde vom Vorstand beauftragt. 

BEGIN ;
  UPDATE issue 
    SET 
      discussion_time = '7 days',
      verification_time = '1 day'
    WHERE 
      id = 3182 AND area_id = 11 AND policy_id = 4 ;
COMMIT ;

BEGIN
UPDATE 1
COMMIT


2013-02-06 ~00:15 (ib) - Rechte für neue Einladungscodes

Am 11.12. wurden neue Einladungscodes eingespielt. Diese waren bisher jedoch noch nicht mit Initiativ- oder Stimmrechten versehen. Da die Codes ab sofort verwendet werden, wird Stimm- und Initiativrecht in der Unit 1 (Bund) gesetzt. 

BEGIN;
  INSERT INTO privilege (unit_id, member_id, voting_right, initiative_right) VALUES
    (1, xxxxx, TRUE, TRUE),
    (1, xxxxx, TRUE, TRUE),
    ...
    (1, xxxxx, TRUE, TRUE),
    (1, xxxxx, TRUE, TRUE);
COMMIT

BEGIN
INSERT 0 50000
COMMIT


2013-02-04 ~14:00 (ib) - Einfrieren der Themen im Vorstandsbereich

Siehe 2012-11-04: 

BEGIN ;
  UPDATE issue 
    SET 
      half_frozen = '2013-02-03 17:00',
      state = 'verification' 
    WHERE 
      area_id in (12, 16) AND 
      policy_id = 11 AND 
      closed ISNULL AND 
      half_frozen ISNULL AND 
      accepted NOTNULL AND 
      accepted < '2013-02-02 17:00' ; 
COMMIT ;

BEGIN
UPDATE 1
COMMIT



2012-12-17 ~18:00 (ib) - Neue Themenbereiche

Es werden die drei neuen Themenbereiche 'Kultur', 'Europa' und 'Haushalt, Finanzen und Steuern' mit den üblichen Parametern angelegt. Der alte Themenbereich 'Wirtschaft, Soziales' wird umbenannt in 'Arbeit und Soziales'. 

BEGIN;

  UPDATE area
    SET name = 'Arbeit und Soziales'
  WHERE
    id = 3 AND name = 'Wirtschaft, Soziales'
  ; 


  INSERT INTO area
    ( id, unit_id, active, name)
  VALUES
    ( 18, 1, true, 'Haushalt, Finanzen und Steuern'),
    ( 19, 1, true, 'Europa'),
    ( 20, 1, true, 'Kultur')
  ;


  INSERT INTO allowed_policy
    ( area_id, policy_id, default_policy)
  VALUES
    ( 18, 2, false),
    ( 18, 3, false),
    ( 18, 4, true ),
    ( 18, 5, false),

    ( 19, 2, false),
    ( 19, 3, false),
    ( 19, 4, true ),
    ( 19, 5, false),

    ( 20, 2, false),
    ( 20, 3, false),
    ( 20, 4, true ),
    ( 20, 5, false)
  ;

COMMIT;

BEGIN
UPDATE 1
INSERT 0 3
INSERT 0 12
COMMIT


2012-12-11 ~16:00 (ib) - Einspielen neuer Einladungscodes

Die von der Clearingstelle übermittelten Codes wurden im System registriert. 

BEGIN;
  INSERT INTO "member" ("invite_code") VALUES 
    ('xxxxx-xxxxx-xxxxx-xxxxx'),
    ('xxxxx-xxxxx-xxxxx-xxxxx'),
      ...
    ('xxxxx-xxxxx-xxxxx-xxxxx'),
    ('xxxxx-xxxxx-xxxxx-xxxxx');
COMMIT;

BEGIN
INSERT 0 50000
COMMIT


2012-12-10 ~23:00 (ib) - Bugfix Nofity E-Mail

Seit Version 2.0.0 wurden Benachrichtigungen zugestellt, bevor die E-Mail Adresse bestätigt war. Die ist im aktuellen Code gefixt und die Fehlerhaften Einträge werden aus der Datenbank entfernt.

Vergleiche: http://dev.liquidfeedback.org/pipermail/announce/2012-December/000020.html 

BEGIN ;
  UPDATE member SET notify_email = NULL WHERE notify_email = notify_email_unconfirmed;                                 
COMMIT ;

BEGIN
UPDATE 87
COMMIT

Bereits vor dem Upgrade wurden folgende Patches eingespielt:

2012-12-09 ~23:00 (ib) - Teilnehmerkreisprüfung

Im Rahmen einer reversen Teilnehmerkreisprüfung wurden von der Clearingstelle 32220 laut Mitgliederverwaltung gültige Einladungscodes übermittelt. Alle Accounts, die keinem dieser Codes zugeordnet sind, werden gesperrt. Nicht benutzte Codes, die sich nicht in dieser Liste befinden werden aus der Datenbank gelöscht. 

BEGIN ;
  UPDATE member
    SET
      locked = TRUE,
      active = FALSE,
      admin_comment = 'Teilnehmerkreis 2012-12-09'
    WHERE
      activated notnull AND
      locked = false AND
      invite_code not in
        (
           'xxxxx-xxxxxx-xxxxx-xxxxx', 'xxxxx-xxxxx-xxxxx-xxxxx-xxxxx', ...
        );

  DELETE FROM member
    WHERE
      activated isnull 
      AND invite_code not in 
        (
           'xxxxx-xxxxxx-xxxxx-xxxxx', 'xxxxx-xxxxx-xxxxx-xxxxx-xxxxx', ...
        );
END ;

BEGIN
UPDATE 316
DELETE 52038
COMMIT

Betroffene Nutzer wurden per E-Mail informiert.


2012-12-09 ~21:00 (ib) - Sperren von Accounts

Von der Clearingstelle wurden 852 verschiedene Codes zum Sperren übermittelt. Im folgenden werden die dazugehörigen existierenden Accounts gesperrt und nicht verwendete Einladungscodes gelöscht: 

BEGIN ;
  UPDATE member
    SET 
      locked = TRUE,
      active = FALSE,
      admin_comment = 'Locked on 2012-12-09'
    WHERE
      invite_code in 
        (
           'xxxxx-xxxxxx-xxxxx-xxxxx', 'xxxxx-xxxxx-xxxxx-xxxxx-xxxxx', ...
        );

  DELETE FROM member
    WHERE
      activated isnull 
      AND invite_code in 
        (
           'xxxxx-xxxxxx-xxxxx-xxxxx', 'xxxxx-xxxxx-xxxxx-xxxxx-xxxxx', ...
        );
END ;

BEGIN
UPDATE 612
DELETE 443
COMMIT

Betroffene Nutzer wurden per E-Mail informiert.


2012-12-03 ~10:30 (ib) - Einfrieren der Themen im Vorstandsbereich

Siehe 2012-11-04: 

BEGIN ;
  UPDATE issue 
    SET
      accepted =    '2012-12-02 16:59', 
      half_frozen = '2012-12-02 17:00',
      state = 'verification' 
    WHERE 
      area_id in (12, 16) AND 
      policy_id = 11 AND 
      closed ISNULL AND 
      half_frozen ISNULL AND 
      accepted NOTNULL ; 
COMMIT ;

BEGIN
UPDATE 3
COMMIT


2012-11-04 ~20:00 (ib) - Einfrieren der Themen im Vorstandsbereich

Alles wie gehabt. Der Vorstandsbereich sollte demnächsten zugunsten eines eigenen Regelwerkes das in den relevanten Bereichen aktiv ist abgeschafft werden. 

BEGIN ;

  UPDATE issue
    SET
      accepted = '2012-11-04 16:59',
      half_frozen = '2012-11-04 17:00',
      state = 'verification'
    WHERE
      area_id in (12, 16) AND
      policy_id = 11 AND
      closed ISNULL AND
      half_frozen ISNULL AND
      accepted NOTNULL ;

COMMIT ;

BEGIN
UPDATE 5
COMMIT


2012-10-28 ~21:00 (ib) - Automatischer Verfall des Stimmrechts

Seit Core Version 1.3.1 unterstützt LiquidFeedback den automatischen Verfall des (delegierten) Stimmrechts von inaktiven Mitgliedern. Der Wert last_login wurde dabei bei allen Teilnehmen initial auf den 6.4.2012 gesetzt, so dass bei der Verfallszeit von 180 Tagen Anfang Oktober das Stimmgewicht der ersten Teilnehmer inaktiviert werden sollte. Dies ist nicht geschehen, weil der Verfall nicht nur im Frontend, sondern auch im Kern konfiguriert werden muss. Das wird hiermit nachgeholt: 

INSERT INTO "system_setting" ("member_ttl") VALUES ('180 days');

INSERT 0 1

Die Anzahl der aktiven Teilnehmer wird ab sofort getrennt auf der Startseite angezeigt.


2012-10-15 ~20:30 (ib) - Upgrade des Kerns auf Version 2.0.12

Es gab einen Bug, der in seltenen Fällen (bei Stimmengleichheit) die Reihenfolge der Abstimmungsergebnisse falsch bestimmt hat. Dieses System kann aufgrund der Prozesse zur 'Akkreditierung' keine verbindlichen Ergebnisse (sondern nur grobe Meinungsbilder) liefern, weshalb sich die Bedeutung des Bugs in Grenzen hält. Da sich die Änderungen in Grenzen halten und eine längere Downtime vermieden werden soll, wird der Kern über einen Patch auf den neuen Stand (Version 2.0.12) gebracht: 


BEGIN;

CREATE OR REPLACE VIEW "liquid_feedback_version" AS
  SELECT * FROM (VALUES ('2.0.12', 2, 0, 12))
  AS "subquery"("string", "major", "minor", "revision");

DROP FUNCTION "vote_ratio"
  ( "initiative"."positive_votes"%TYPE,  
    "initiative"."negative_votes"%TYPE );

CREATE OR REPLACE FUNCTION "calculate_ranks"("issue_id_p" "issue"."id"%TYPE)
  RETURNS VOID
  LANGUAGE 'plpgsql' VOLATILE AS $$
    DECLARE
      "issue_row"         "issue"%ROWTYPE;
      "policy_row"        "policy"%ROWTYPE;
      "dimension_v"       INTEGER;
      "vote_matrix"       INT4[][];  -- absolute votes
      "matrix"            INT8[][];  -- defeat strength / best paths
      "i"                 INTEGER;
      "j"                 INTEGER;
      "k"                 INTEGER;
      "battle_row"        "battle"%ROWTYPE;
      "rank_ary"          INT4[];
      "rank_v"            INT4;
      "done_v"            INTEGER;
      "winners_ary"       INTEGER[];
      "initiative_id_v"   "initiative"."id"%TYPE;
    BEGIN
      SELECT * INTO "issue_row"
        FROM "issue" WHERE "id" = "issue_id_p"
        FOR UPDATE;
      SELECT * INTO "policy_row"
        FROM "policy" WHERE "id" = "issue_row"."policy_id";
      SELECT count(1) INTO "dimension_v"
        FROM "battle_participant" WHERE "issue_id" = "issue_id_p";
      -- Create "vote_matrix" with absolute number of votes in pairwise
      -- comparison:
      "vote_matrix" := array_fill(NULL::INT4, ARRAY["dimension_v", "dimension_v"]);
      "i" := 1;
      "j" := 2;
      FOR "battle_row" IN
        SELECT * FROM "battle" WHERE "issue_id" = "issue_id_p"
        ORDER BY
        "winning_initiative_id" NULLS LAST,
        "losing_initiative_id" NULLS LAST
      LOOP
        "vote_matrix"["i"]["j"] := "battle_row"."count";
        IF "j" = "dimension_v" THEN
          "i" := "i" + 1;
          "j" := 1;
        ELSE
          "j" := "j" + 1;
          IF "j" = "i" THEN
            "j" := "j" + 1;
          END IF;
        END IF;
      END LOOP;
      IF "i" != "dimension_v" OR "j" != "dimension_v" + 1 THEN
        RAISE EXCEPTION 'Wrong battle count (should not happen)';
      END IF;
      -- Store defeat strengths in "matrix" using "defeat_strength"
      -- function:
      "matrix" := array_fill(NULL::INT8, ARRAY["dimension_v", "dimension_v"]);
      "i" := 1;
      LOOP
        "j" := 1;
        LOOP
          IF "i" != "j" THEN
            "matrix"["i"]["j"] := "defeat_strength"(
              "vote_matrix"["i"]["j"],
              "vote_matrix"["j"]["i"]
            );
          END IF;
          EXIT WHEN "j" = "dimension_v";
          "j" := "j" + 1;
        END LOOP;
        EXIT WHEN "i" = "dimension_v";
        "i" := "i" + 1;
      END LOOP;
      -- Find best paths:
      "i" := 1;
      LOOP
        "j" := 1;
        LOOP
          IF "i" != "j" THEN
            "k" := 1;
            LOOP
              IF "i" != "k" AND "j" != "k" THEN
                IF "matrix"["j"]["i"] < "matrix"["i"]["k"] THEN
                  IF "matrix"["j"]["i"] > "matrix"["j"]["k"] THEN
                    "matrix"["j"]["k"] := "matrix"["j"]["i"];
                  END IF;
                ELSE
                  IF "matrix"["i"]["k"] > "matrix"["j"]["k"] THEN
                    "matrix"["j"]["k"] := "matrix"["i"]["k"];
                  END IF;
                END IF;
              END IF;
              EXIT WHEN "k" = "dimension_v";
              "k" := "k" + 1;
            END LOOP;
          END IF;
          EXIT WHEN "j" = "dimension_v";
          "j" := "j" + 1;
        END LOOP;
        EXIT WHEN "i" = "dimension_v";
        "i" := "i" + 1;
      END LOOP;
      -- Determine order of winners:
      "rank_ary" := array_fill(NULL::INT4, ARRAY["dimension_v"]);
      "rank_v" := 1;
      "done_v" := 0;
      LOOP
        "winners_ary" := '{}';
        "i" := 1;
        LOOP
          IF "rank_ary"["i"] ISNULL THEN
            "j" := 1;
            LOOP
              IF
                "i" != "j" AND
                "rank_ary"["j"] ISNULL AND
                "matrix"["j"]["i"] > "matrix"["i"]["j"]
              THEN
                -- someone else is better
                EXIT;
              END IF;
              IF "j" = "dimension_v" THEN
                -- noone is better
                "winners_ary" := "winners_ary" || "i";
                EXIT;
              END IF;
              "j" := "j" + 1;
            END LOOP;
          END IF;
          EXIT WHEN "i" = "dimension_v";
          "i" := "i" + 1;
        END LOOP;
        "i" := 1;
        LOOP
          "rank_ary"["winners_ary"["i"]] := "rank_v";
          "done_v" := "done_v" + 1;
          EXIT WHEN "i" = array_upper("winners_ary", 1);
          "i" := "i" + 1;
        END LOOP;
        EXIT WHEN "done_v" = "dimension_v";
        "rank_v" := "rank_v" + 1;
      END LOOP;
      -- write preliminary results:
      "i" := 1;
      FOR "initiative_id_v" IN
        SELECT "id" FROM "initiative"
        WHERE "issue_id" = "issue_id_p" AND "admitted"
        ORDER BY "id"
      LOOP
        UPDATE "initiative" SET
          "direct_majority" =
            CASE WHEN "policy_row"."direct_majority_strict" THEN
              "positive_votes" * "policy_row"."direct_majority_den" >
              "policy_row"."direct_majority_num" * ("positive_votes"+"negative_votes")
            ELSE
              "positive_votes" * "policy_row"."direct_majority_den" >=
              "policy_row"."direct_majority_num" * ("positive_votes"+"negative_votes")
            END
            AND "positive_votes" >= "policy_row"."direct_majority_positive"
            AND "issue_row"."voter_count"-"negative_votes" >=
                "policy_row"."direct_majority_non_negative",
            "indirect_majority" =
            CASE WHEN "policy_row"."indirect_majority_strict" THEN
              "positive_votes" * "policy_row"."indirect_majority_den" >
              "policy_row"."indirect_majority_num" * ("positive_votes"+"negative_votes")
            ELSE
              "positive_votes" * "policy_row"."indirect_majority_den" >=
              "policy_row"."indirect_majority_num" * ("positive_votes"+"negative_votes")
            END
            AND "positive_votes" >= "policy_row"."indirect_majority_positive"
            AND "issue_row"."voter_count"-"negative_votes" >=
                "policy_row"."indirect_majority_non_negative",
          "schulze_rank"           = "rank_ary"["i"],
          "better_than_status_quo" = "rank_ary"["i"] < "rank_ary"["dimension_v"],
          "worse_than_status_quo"  = "rank_ary"["i"] > "rank_ary"["dimension_v"],
          "multistage_majority"    = "rank_ary"["i"] >= "rank_ary"["dimension_v"],
          "reverse_beat_path"      = "matrix"["dimension_v"]["i"] >= 0,
          "eligible"               = FALSE,
          "winner"                 = FALSE,
          "rank"                   = NULL  -- NOTE: in cases of manual reset of issue state
          WHERE "id" = "initiative_id_v";
        "i" := "i" + 1;
      END LOOP;
      IF "i" != "dimension_v" THEN
        RAISE EXCEPTION 'Wrong winner count (should not happen)';
      END IF;
      -- take indirect majorities into account:
      LOOP
        UPDATE "initiative" SET "indirect_majority" = TRUE
          FROM (
            SELECT "new_initiative"."id" AS "initiative_id"
            FROM "initiative" "old_initiative"
            JOIN "initiative" "new_initiative"
              ON "new_initiative"."issue_id" = "issue_id_p"
              AND "new_initiative"."indirect_majority" = FALSE
            JOIN "battle" "battle_win"
              ON "battle_win"."issue_id" = "issue_id_p"
              AND "battle_win"."winning_initiative_id" = "new_initiative"."id"
              AND "battle_win"."losing_initiative_id" = "old_initiative"."id"
            JOIN "battle" "battle_lose"
              ON "battle_lose"."issue_id" = "issue_id_p"
              AND "battle_lose"."losing_initiative_id" = "new_initiative"."id"
              AND "battle_lose"."winning_initiative_id" = "old_initiative"."id"
            WHERE "old_initiative"."issue_id" = "issue_id_p"
            AND "old_initiative"."indirect_majority" = TRUE
            AND CASE WHEN "policy_row"."indirect_majority_strict" THEN
              "battle_win"."count" * "policy_row"."indirect_majority_den" >
              "policy_row"."indirect_majority_num" *
              ("battle_win"."count"+"battle_lose"."count")
            ELSE
              "battle_win"."count" * "policy_row"."indirect_majority_den" >=
              "policy_row"."indirect_majority_num" *
              ("battle_win"."count"+"battle_lose"."count")
            END
            AND "battle_win"."count" >= "policy_row"."indirect_majority_positive"
            AND "issue_row"."voter_count"-"battle_lose"."count" >=
                "policy_row"."indirect_majority_non_negative"
          ) AS "subquery"
          WHERE "id" = "subquery"."initiative_id";
        EXIT WHEN NOT FOUND;
      END LOOP;
      -- set "multistage_majority" for remaining matching initiatives:
      UPDATE "initiative" SET "multistage_majority" = TRUE
        FROM (
          SELECT "losing_initiative"."id" AS "initiative_id"
          FROM "initiative" "losing_initiative"
          JOIN "initiative" "winning_initiative"
            ON "winning_initiative"."issue_id" = "issue_id_p"
            AND "winning_initiative"."admitted"
          JOIN "battle" "battle_win"
            ON "battle_win"."issue_id" = "issue_id_p"
            AND "battle_win"."winning_initiative_id" = "winning_initiative"."id"
            AND "battle_win"."losing_initiative_id" = "losing_initiative"."id"
          JOIN "battle" "battle_lose"
            ON "battle_lose"."issue_id" = "issue_id_p"
            AND "battle_lose"."losing_initiative_id" = "winning_initiative"."id"
            AND "battle_lose"."winning_initiative_id" = "losing_initiative"."id"
          WHERE "losing_initiative"."issue_id" = "issue_id_p"
          AND "losing_initiative"."admitted"
          AND "winning_initiative"."schulze_rank" <
              "losing_initiative"."schulze_rank"
          AND "battle_win"."count" > "battle_lose"."count"
          AND (
            "battle_win"."count" > "winning_initiative"."positive_votes" OR
            "battle_lose"."count" < "losing_initiative"."negative_votes" )
        ) AS "subquery"
        WHERE "id" = "subquery"."initiative_id";
      -- mark eligible initiatives:
      UPDATE "initiative" SET "eligible" = TRUE
        WHERE "issue_id" = "issue_id_p"
        AND "initiative"."direct_majority"
        AND "initiative"."indirect_majority"
        AND "initiative"."better_than_status_quo"
        AND (
          "policy_row"."no_multistage_majority" = FALSE OR
          "initiative"."multistage_majority" = FALSE )
        AND (
          "policy_row"."no_reverse_beat_path" = FALSE OR
          "initiative"."reverse_beat_path" = FALSE );
      -- mark final winner:
      UPDATE "initiative" SET "winner" = TRUE
        FROM (
          SELECT "id" AS "initiative_id"
          FROM "initiative"
          WHERE "issue_id" = "issue_id_p" AND "eligible"
          ORDER BY
            "schulze_rank",
            "id"
          LIMIT 1
        ) AS "subquery"
        WHERE "id" = "subquery"."initiative_id";
      -- write (final) ranks:
      "rank_v" := 1;
      FOR "initiative_id_v" IN
        SELECT "id"
        FROM "initiative"
        WHERE "issue_id" = "issue_id_p" AND "admitted"
        ORDER BY
          "winner" DESC,
          "eligible" DESC,
          "schulze_rank",
          "id"
      LOOP
        UPDATE "initiative" SET "rank" = "rank_v"
          WHERE "id" = "initiative_id_v";
        "rank_v" := "rank_v" + 1;
      END LOOP;
      -- set schulze rank of status quo and mark issue as finished:
      UPDATE "issue" SET
        "status_quo_schulze_rank" = "rank_ary"["dimension_v"],
        "state" =
          CASE WHEN EXISTS (
            SELECT NULL FROM "initiative"
            WHERE "issue_id" = "issue_id_p" AND "winner"
          ) THEN
            'finished_with_winner'::"issue_state"
          ELSE
            'finished_without_winner'::"issue_state"
          END,
        "ranks_available" = TRUE
        WHERE "id" = "issue_id_p";
      RETURN;
    END;
  $$;

COMMIT;

BEGIN
CREATE VIEW
psql:core_c2.0.12_patch.sql:10: NOTICE:  type reference initiative.positive_votes%TYPE converted to integer
psql:core_c2.0.12_patch.sql:10: NOTICE:  type reference initiative.negative_votes%TYPE converted to integer
DROP FUNCTION
psql:core_c2.0.12_patch.sql:312: NOTICE:  type reference issue.id%TYPE converted to integer
CREATE FUNCTION
COMMIT


2012-10-08 ~23:30 (ib) - Letzte Abstimmungen für BPT12.2 starten

Die Themen, die am 1.10. manuell in die Diskussionsphase versetzt wurden gehen automatisch rechtzeitig in die Abstimmungsphase über, weil die Diskussionsphase im gleichen Schritt auf sieben Tage verkürzt wurde. Die Themen, die in der Woche vor dem 1.10. selbständig die Diskussionsphase erreicht haben, würden zwei Wochen in Diskussion bleiben und damit zu spät in die Abstimmungsphase gehen. Diese Themen werden nun manuell in die Abstimmung versetzt: 

BEGIN;

  SELECT id FROM issue
  WHERE
    area_id in (2,3,6,4,1,7,5,9,11,8,17)
    AND policy_id = 2
    AND state = 'verification'
    AND verification_time > '7 days'
    AND accepted < '2012-09-29 00:06' ;
  
  SELECT id FROM issue
  WHERE
    area_id in (2,3,6,4,1,7,5,9,11,8,17)
    AND policy_id = 1
    AND state = 'verification'
    AND verification_time > '7 days'
    AND accepted < '2012-09-29 00:06' ;
  
  UPDATE issue
  SET
    state = 'voting',
    fully_frozen = '2012-10-08 23:42'
  WHERE
    area_id in (2,3,6,4,1,7,5,9,11,8,17)
    AND policy_id in (1,2)
    AND state = 'verification'
    AND verification_time > '7 days'
    AND accepted < '2012-09-29 00:06' ;

COMMIT;

BEGIN
  id
------
 2497
 2542
 2531
 2501
 2577
 2544
 2567
 2537
 2519
 2572
 2578
 2487
 2547
 2502
 2569
(15 rows)

  id
------
 2556
(1 row)

psql:btp-freeze-2.sql:29: ERROR:  new row for relation "issue" violates check constraint "last_snapshot_on_full_freeze"
ROLLBACK

Das manuelle verändern des Abstimmungsdatums verursachte einen Fehler, weil die Software sicherstellt, dass gleichzeitig ein Snapshot erstellt wird. Der ganze Commit wurd per rollback zurückgenommen und es wurden keine Änderungen an der Datenbank vorgenommen. Im folgenden werden die entsprechenden Themen mit der Funktion manual_freeze() in die Abstimmung versetzt: 

BEGIN;
  SELECT manual_freeze(2497);
  SELECT manual_freeze(2542);
  SELECT manual_freeze(2531);
  SELECT manual_freeze(2501);
  SELECT manual_freeze(2577);
  SELECT manual_freeze(2544);
  SELECT manual_freeze(2567);
  SELECT manual_freeze(2537);
  SELECT manual_freeze(2519);
  SELECT manual_freeze(2572);
  SELECT manual_freeze(2578);
  SELECT manual_freeze(2487);
  SELECT manual_freeze(2547);
  SELECT manual_freeze(2502);
  SELECT manual_freeze(2569);
  SELECT manual_freeze(2556);
COMMIT;

Dabei traten keine Fehler auf und die Abstimmung der 16 Themen wurde gestartet.


2012-10-01 ~23:42 (ib) - Einfrieren für den BPT12.2

Jetzt werden die Themen eingefroren und die Länge der Eingefrorenenphase verkürzt: 

BEGIN;

  SELECT id FROM issue
  WHERE
    area_id in (2,3,6,4,1,7,5,9,11,8,17)
    AND policy_id = 2
    AND state = 'discussion'
    AND accepted < '2012-09-29 00:06' ;

  SELECT id FROM issue
  WHERE
    area_id in (2,3,6,4,1,7,5,9,11,8,17)
    AND policy_id = 1
    AND state = 'discussion'
    AND accepted < '2012-09-29 00:06' ;

  UPDATE issue
  SET
    state = 'verification',
    half_frozen = '2012-10-01 23:42',
    verification_time = '7 days'
  WHERE
    area_id in (2,3,6,4,1,7,5,9,11,8,17)
    AND policy_id in (1,2)
    AND state = 'discussion'
    AND accepted < '2012-09-29 00:06' ;

COMMIT;

BEGIN
  id  
------
 2641
 2652
 2688
 2666
 2664
 2589
 2588
 2600
 2587
 2645
 2644
 2704
 2592
 2674
 2667
 2657
 2761
 2647
 2606
 2691
 2692
 2668
 2662
 2716
 2648
 2703
 2752
 2611
 2670
 2759
 2801
 2800
 2747
 2745
 2638
 2601
 2721
 2637
 2658
 2709
 2676
 2769
 2748
 2699
 2698
 2701
 2697
 2583
 2628
 2607
 2705
 2700
 2702
 2714
 2732
 2669
 2744
 2590
 2802
 2805
 2804
 2770
 2784
 2636
 2713
 2789
 2779
 2807
 2787
 2777
 2775
(71 rows)

  id  
------
 2630
 2795
 2725
 2734
 2765
 2796
 2738
(7 rows)

UPDATE 78
COMMIT


2012-10-01 ~20:00 (ib) - Einfrieren für den BPT12.2 (Simulation)

Heute Nacht werden gemäß Beschluss die Initiativen für den Bundesparteitag in Bochum eingefroren. Da es mit Version 2.0 Änderungen an der Datenbank und den Constraints gab, wird die Query kurz getestet.

Die Deadline zum Erreichen des Quorums war am 28.09.2012 um 23:42. Da die Quoren jedoch nur alle 20 Minuten berechnet werden, werden alle Initiativen eingefroren, die das Quorum bis zum Ende der ersten Berechnung nach Deadline (am 29.09.2012 um 00:06 Uhr) erreicht haben. 

BEGIN;
  UPDATE issue
  SET
    state = 'verification',
    half_frozen = '2012-10-01 23:42',
    verification_time = '7 days'
  WHERE
    area_id in (2,3,6,4,1,7,5,9,11,8,17)
    AND policy_id in (1,2)
    AND state = 'discussion'
    AND accepted < '2012-09-29 00:06' ;
  ROLLBACK ;
COMMIT;

BEGIN
UPDATE 78
ROLLBACK
psql:btp-freeze-simulate.sql:17: WARNING:  there is no transaction in progress
COMMIT

Diese Simulation stellt aufgrund des Rollbacks keinen wirklichen Datenbankeingriff dar.


2012-09-27 ~21:45 (ib) - Sperren von Accounts

Von der Clearingstelle wurden 417 verschiedene Codes zum Sperren übermittelt (fünf davon waren bereits gesperrt). Im folgenden werden die dazugehörigen existierenden Accounts gesperrt und nicht verwendete Einladungscodes gelöscht: 

BEGIN ;

  UPDATE member
    SET
      locked = TRUE,
      active = FALSE,
      admin_comment = 'Locked on 2012-09-27'
    WHERE
      invite_code in
        (
          'xxxxx-xxxxx-xxxxx-xxxxx',
          'xxxxx-xxxxx-xxxxx-xxxxx',
          'xxxxx-xxxxx-xxxxx-xxxxx' 
        );

  DELETE FROM member
    WHERE
      activated isnull 
      AND invite_code in 
        (
           'xxxxx-xxxxx-xxxxx-xxxxx',
           'xxxxx-xxxxx-xxxxx-xxxxx',
           'xxxxx-xxxxx-xxxxx-xxxxx'
        );

END ;

BEGIN
UPDATE 412
DELETE 292
COMMIT


2012-09-25 ~19:30 (ib) - Änderung des Lockings

Das Locking wird ein weiteres Mal geändert, da es zu neuen Deadlocks beim Setzen von Delegation gekommen war. Die Funktion lock_issue wird wie folgt ersetzt: 

COMMIT;
CREATE OR REPLACE FUNCTION "lock_issue"
   ( "issue_id_p" "issue"."id"%TYPE )
   RETURNS VOID
   LANGUAGE 'plpgsql' VOLATILE AS $$
     BEGIN
       PERFORM NULL FROM "issue" WHERE "id" = "issue_id_p" FOR UPDATE;
       PERFORM NULL FROM "member" WHERE "active" FOR SHARE;
       LOCK TABLE "member"     IN SHARE MODE;
       LOCK TABLE "privilege"  IN SHARE MODE;
       LOCK TABLE "membership" IN SHARE MODE;
       LOCK TABLE "policy"     IN SHARE MODE;
       LOCK TABLE "delegation" IN SHARE MODE;
       LOCK TABLE "direct_population_snapshot"     IN EXCLUSIVE MODE;
       LOCK TABLE "delegating_population_snapshot" IN EXCLUSIVE MODE;
       LOCK TABLE "direct_interest_snapshot"       IN EXCLUSIVE MODE;
       LOCK TABLE "delegating_interest_snapshot"   IN EXCLUSIVE MODE;
       LOCK TABLE "direct_supporter_snapshot"      IN EXCLUSIVE MODE;
       RETURN;
     END;
   $$;
END;


2012-09-25 ~00:15 (ib) - Änderung des Lockings

Mit dem folgendem patch wird das Locking erneut geändern, weil es durch die letzte Änderung zu anderen Deadlocks im Zählprozess gekommen war und die Performance nachgelassen hatte:

http://www.public-software-group.org/mercurial/liquid_feedback_core/rev/bcfde30040f6 

# HG changeset patch
# User jbe
# Date 1348519646 -7200
# Node ID bcfde30040f699031749b508c270fc151e1ba63a
# Parent  69d6fba0f84cbb9f3d591f40147a67433ee0ef0a
Use SHARE MODE table locks in function "lock_issue"("issue"."id") for tables neither referenced nor changed

diff -r 69d6fba0f84c -r bcfde30040f6 core.sql
--- a/core.sql	Thu Sep 13 17:02:22 2012 +0200
+++ b/core.sql	Mon Sep 24 22:47:26 2012 +0200
@@ -2925,10 +2925,9 @@
   RETURNS VOID
   LANGUAGE 'plpgsql' VOLATILE AS $$
     BEGIN
-      LOCK TABLE "member"     IN EXCLUSIVE MODE;
-      LOCK TABLE "privilege"  IN EXCLUSIVE MODE;
-      LOCK TABLE "membership" IN EXCLUSIVE MODE;
-      LOCK TABLE "policy"     IN EXCLUSIVE MODE;
+      -- The following locking order is used:
+      -- 1st) row-level lock on the issue
+      -- 2nd) table-level locks in order of occurrence in the core.sql file
       PERFORM NULL FROM "issue" WHERE "id" = "issue_id_p" FOR UPDATE;
       -- NOTE: The row-level exclusive lock in combination with the
       -- share_row_lock_issue(_via_initiative)_trigger functions (which
@@ -2936,7 +2935,11 @@
       -- is changed, which could affect calculation of snapshots or
       -- counting of votes. Table "delegation" must be table-level-locked,
       -- as it also contains issue- and global-scope delegations.
-      LOCK TABLE "delegation" IN EXCLUSIVE MODE;
+      LOCK TABLE "member"     IN EXCLUSIVE MODE;  -- exclusive avoids deadlocks
+      LOCK TABLE "privilege"  IN SHARE MODE;
+      LOCK TABLE "membership" IN SHARE MODE;
+      LOCK TABLE "policy"     IN SHARE MODE;
+      LOCK TABLE "delegation" IN SHARE MODE;
       LOCK TABLE "direct_population_snapshot"     IN EXCLUSIVE MODE;
       LOCK TABLE "delegating_population_snapshot" IN EXCLUSIVE MODE;
       LOCK TABLE "direct_interest_snapshot"       IN EXCLUSIVE MODE;

Die Funktion lock_issue wird wie folgt ersetzt: 

COMMIT;
CREATE OR REPLACE FUNCTION "lock_issue"
   ( "issue_id_p" "issue"."id"%TYPE )
   RETURNS VOID
   LANGUAGE 'plpgsql' VOLATILE AS $$
     BEGIN
       -- The following locking order is used:
       -- 1st) row-level lock on the issue
       -- 2nd) table-level locks in order of occurrence in the core.sql file
       PERFORM NULL FROM "issue" WHERE "id" = "issue_id_p" FOR UPDATE;
       -- NOTE: The row-level exclusive lock in combination with the
       -- share_row_lock_issue(_via_initiative)_trigger functions (which
       -- acquire a row-level share lock on the issue) ensure that no data
       -- is changed, which could affect calculation of snapshots or
       -- counting of votes. Table "delegation" must be table-level-locked,
       -- as it also contains issue- and global-scope delegations.
       LOCK TABLE "member"     IN EXCLUSIVE MODE;  -- exclusive avoids deadlocks
       LOCK TABLE "privilege"  IN SHARE MODE;
       LOCK TABLE "membership" IN SHARE MODE;
       LOCK TABLE "policy"     IN SHARE MODE;
       LOCK TABLE "delegation" IN SHARE MODE;
       LOCK TABLE "direct_population_snapshot"     IN EXCLUSIVE MODE;
       LOCK TABLE "delegating_population_snapshot" IN EXCLUSIVE MODE;
       LOCK TABLE "direct_interest_snapshot"       IN EXCLUSIVE MODE;
       LOCK TABLE "delegating_interest_snapshot"   IN EXCLUSIVE MODE;
       LOCK TABLE "direct_supporter_snapshot"      IN EXCLUSIVE MODE;
       RETURN;
     END;
   $$;
END;


2012-09-24 ~8:00 (ib) - Verhinderung von Deadlocks

In der Vergangenheit sind beim Ändern von Profilseiten gelegentlich Deadlocks aufgetreten. Der folgende Patch der Entwickler soll dies verhindern und wird Teil von LiquidFeedback 2.1 sein:

http://www.public-software-group.org/mercurial/liquid_feedback_core/rev/69d6fba0f84c 

# HG changeset patch
# User jbe
# Date 1347548542 -7200
# Node ID 69d6fba0f84cbb9f3d591f40147a67433ee0ef0a
# Parent  e818f83e133bc545681b4bc06ce3c4f280de4672
Use EXCLUSIVE MODE table locks in function "lock_issue"("issue"."id")

Avoids deadlocks caused by explicit FOR UPDATE row locks when updating member statements and implicit FOR SHARE row locks when writing snapshots.

diff -r e818f83e133b -r 69d6fba0f84c core.sql
--- a/core.sql	Wed Jun 20 21:22:02 2012 +0200
+++ b/core.sql	Thu Sep 13 17:02:22 2012 +0200
@@ -2925,10 +2925,10 @@
   RETURNS VOID
   LANGUAGE 'plpgsql' VOLATILE AS $$
     BEGIN
-      LOCK TABLE "member"     IN SHARE MODE;
-      LOCK TABLE "privilege"  IN SHARE MODE;
-      LOCK TABLE "membership" IN SHARE MODE;
-      LOCK TABLE "policy"     IN SHARE MODE;
+      LOCK TABLE "member"     IN EXCLUSIVE MODE;
+      LOCK TABLE "privilege"  IN EXCLUSIVE MODE;
+      LOCK TABLE "membership" IN EXCLUSIVE MODE;
+      LOCK TABLE "policy"     IN EXCLUSIVE MODE;
       PERFORM NULL FROM "issue" WHERE "id" = "issue_id_p" FOR UPDATE;
       -- NOTE: The row-level exclusive lock in combination with the
       -- share_row_lock_issue(_via_initiative)_trigger functions (which
@@ -2936,7 +2936,7 @@
       -- is changed, which could affect calculation of snapshots or
       -- counting of votes. Table "delegation" must be table-level-locked,
       -- as it also contains issue- and global-scope delegations.
-      LOCK TABLE "delegation" IN SHARE MODE;
+      LOCK TABLE "delegation" IN EXCLUSIVE MODE;
       LOCK TABLE "direct_population_snapshot"     IN EXCLUSIVE MODE;
       LOCK TABLE "delegating_population_snapshot" IN EXCLUSIVE MODE;
       LOCK TABLE "direct_interest_snapshot"       IN EXCLUSIVE MODE;

Die Funktion lock_issue wird wie folgt ersetzt: 

CREATE OR REPLACE FUNCTION "lock_issue"
   ( "issue_id_p" "issue"."id"%TYPE )
   RETURNS VOID
   LANGUAGE 'plpgsql' VOLATILE AS $$
     BEGIN
       LOCK TABLE "member"     IN EXCLUSIVE MODE;
       LOCK TABLE "privilege"  IN EXCLUSIVE MODE;
       LOCK TABLE "membership" IN EXCLUSIVE MODE;
       LOCK TABLE "policy"     IN EXCLUSIVE MODE;
       PERFORM NULL FROM "issue" WHERE "id" = "issue_id_p" FOR UPDATE;
       LOCK TABLE "delegation" IN EXCLUSIVE MODE;
       LOCK TABLE "direct_population_snapshot"     IN EXCLUSIVE MODE;
       LOCK TABLE "delegating_population_snapshot" IN EXCLUSIVE MODE;
       LOCK TABLE "direct_interest_snapshot"       IN EXCLUSIVE MODE;
       LOCK TABLE "delegating_interest_snapshot"   IN EXCLUSIVE MODE;
       LOCK TABLE "direct_supporter_snapshot"      IN EXCLUSIVE MODE;
       RETURN;
     END;
   $$;


2012-09-01 ~04:15 (ib) - Beschreibung des Themenbereichs Spielwiese

Aufgrund mehrerer Anfragen wurde zum Themenbereich ein kurzer, erklärender Informationstext hinzugefügt: 

BEGIN;
  UPDATE 
    area
  SET 
    description = 'Der Themenbereich Sandkasten/Spielwiese ist zum Ausprobieren und Spaßhaben gedacht. Wer will kann sich gerne zum Obst machen. Ironie ist hier erlaubt; Beleidigungen und Verleumdungen natürlich nicht (siehe Nutzungsbedingungen). Die Abstimmungsergebnisse sind nicht wirklich ernst zu nehmen ;).' 
  WHERE 
    id = 12 ;
COMMIT;

BEGIN
UPDATE 1
COMMIT


2012-08-31 ~11:00 (ib) - Gelockte Mitglieder sind immer inaktiv

Zu sperrende Benutzer müssen immer explizit als gelockt und inaktiv gesetzt werden, weil die Felder locked und active völlig unabhängig voneinander ausgewertet werden. Wenn ein Benutzer manuell nur inaktiv gesetzt wird, so wird der Status nach dem nächsten Login automatisch wieder auf aktiv gesetzt. Wenn ein Benutzer manuell nur als gelockt gesetzt wurde, wird der Account erst nach Ablauf des festgelegten Zeitraums (aktuell 180 Tage) automatisch vollständig inaktiviert und entsprechend angezeigt. 

BEGIN;
  UPDATE member SET active = FALSE WHERE locked = TRUE AND active = TRUE;
COMMIT;

BEGIN
UPDATE 466
COMMIT


2012-08-13 ~02:00 (ib) - Upgrade auf LiquidFeedback 2.0

Die Umstellung auf LiquidFeedback Kern 2.0.11 fand parallel mit der Migration auf einen neue Serverhardware statt. Die Datenbank wurde mit pg_dump exportiert und auf dem neuen Server eingespielt. Danach wurden die folgenden Update-Skripte ausgeführt:

Der Name der einzigen Gliederung wurde von "Main" auf "Bundesebene" geändert: 

BEGIN ;
  UPDATE 
    unit
  SET 
    name = 'Bundesebene'
  WHERE
    id = 1 ;
COMMIT ;

BEGIN
UPDATE 11
COMMIT

Das Mehrheitskriterium wurde in allen Themenbereichen auf "strict" gesetzt (war vorher uneinheitlich): 

BEGIN ;
  UPDATE 
    policy
  SET 
    direct_majority_strict = TRUE ;
COMMIT ;

BEGIN
UPDATE 11
COMMIT

2012-08-12 ~18:15 (ib) - Einfrieren der Nachzüglerzur BuVo-Sitzung

Es gab wieder ein Missverständnis bezüglich des Workflows und einige Initiativen wurden zu spät eingestellt. Die werden hiermit auch noch eingefroren. Wegen Datenbank-Constraints werden auch die Zeitpunkte der Erstellung und des Diskussionsbeginns zurückdatiert. Die drei Initiativen wurden eigentlich kurz vor 17 Uhr eingestellt und sind dann direkt in die Diskussionsphase gegangen. 

BEGIN ;
  
  UPDATE issue
    SET 
      created     = '2012-08-10 17:00', 
      accepted    = '2012-08-11 17:00', 
      half_frozen = '2012-08-12 17:00'
    WHERE
      area_id in (12, 16) AND
      policy_id = 11 AND
      closed ISNULL AND
      half_frozen ISNULL AND
      accepted NOTNULL ;
COMMIT ;

BEGIN
UPDATE 3
COMMIT

2012-08-12 ~13:00 (ib) - Einfrieren der Themen zur BuVo-Sitzung

Wie gehabt. Wegen der Migration auf 2.0 noch mal von Hand. 

BEGIN ;
  UPDATE issue
    SET half_frozen = '2012-08-12 17:00'
    WHERE
      area_id in (12, 16) AND
      policy_id = 11 AND
      closed ISNULL AND
      half_frozen ISNULL AND
      accepted NOTNULL AND
      accepted < '2012-08-11 17:00' ;
COMMIT ;

BEGIN
UPDATE 5
COMMIT


2012-08-10 ~06:30 (ib) - Sperrungen und Entsperrungen

Über die Clearingstelle wurden Listen mit 47 zu sperrenden und 46 zu entsperrenden Einladungscodes übermittelt.

Löschen unbenutzter zu sperrender Invitecodes: 

BEGIN;
  DELETE FROM invite_code
   WHERE (used ISNULL) AND (member_id ISNULL) AND (code in (
     '?????-?????-?????-?????',
     [...],
     '?????-?????-?????-?????'
  ));
COMMIT;

BEGIN
DELETE 33
COMMIT

Sperren von Accounts: 

BEGIN;
  UPDATE member
  SET locked = TRUE
  WHERE id IN (
    ???,
    [...],
    ???
  );
COMMIT;

BEGIN
UPDATE 13
COMMIT

Entsperren der Accounts: 

BEGIN;
  UPDATE member
  SET locked = FALSE
  WHERE locked = TRUE AND id IN (
     ???,
     [...],
     ???
  );
COMMIT;

BEGIN
UPDATE 15
COMMIT

Die Benutzer wurden über die im System hinterlegte E-Mail-Adresse informiert.


2012-05-05 ~5:30 (ib) - Sperrungen

Über die Clearingstelle wurde eine Liste mit 24 zu sperrenden Einladungscodes übermittelt.

Entfernen von unbenutzten Einladungscodes: 

BEGIN;
  DELETE FROM invite_code
   WHERE (used ISNULL) AND (member_id ISNULL) AND (code in (
     '?????-?????-?????-?????',
     [...],
     '?????-?????-?????-?????'
  ));
COMMIT;

BEGIN
DELETE 17
COMMIT

Sperren von existierenden Accounts: 

BEGIN;
  UPDATE member
  SET locked = TRUE
  WHERE id IN (
    ???,
    [...],
    ???
  );
COMMIT;

BEGIN
UPDATE 6
COMMIT

Die betroffenen Benutzer wurden per E-Mail informiert.


2012-07-31 ~13:00 (ib) - Entsperrungen

Über die Clearingstelle wurde eine Liste mit 53 zu entsperrenden Einladungscodes übermittelt. Die Benutzer waren vorher gesperrt worden, hatten um eine Reaktivierung ihres Accounts gebeten, wurden über die in der Mitgliederdatenbank hinterlegte E-Mail-Adresse angeschrieben und um Bestätigung gebeten.

Entsperren der Accounts: 

BEGIN;
  UPDATE member
  SET locked = FALSE
  WHERE locked = TRUE AND id IN (
     ???,
     [...],
     ???
  );
COMMIT;

BEGIN
UPDATE 53
COMMIT

Die Benutzer wurden über die im System hinterlegte E-Mail-Adresse informiert.


2012-07-30 ~19:00 (ib) - Sperrungen

Über die Clearingstelle wurde eine Liste mit 605 zu sperrenden Einladungscodes übermittelt.

Entfernen von unbenutzten Einladungscodes: 

BEGIN;
  DELETE FROM invite_code
   WHERE (used ISNULL) AND (member_id ISNULL) AND (code in (
     '?????-?????-?????-?????',
     [...],
     '?????-?????-?????-?????'
  ));
COMMIT;

BEGIN
DELETE 67
COMMIT

Sperren von existierenden Accounts: 

BEGIN;
  UPDATE member
  SET locked = TRUE
  WHERE id IN (
    ???,
    [...],
    ???
  );
COMMIT;

BEGIN
UPDATE 121
COMMIT

Die betroffenen Benutzer wurden per E-Mail informiert.


2012-07-30 ~18:00 (ib) - Einfrieren weiterer Themen zur BuVo-Sitzung

Zwei Initiativen wurden aufgrund eines Missverständnisses etwas zu spät eingereicht und hiermit manuell noch in die Abstimmungsphase versetzt. Für die Zukunft soll die GO angepasst werden, so dass klar ist, dass Anträge möglichst 6 Tage vor der Sitzung eingereicht sind. Wegen Datenbank-Constraints werden auch die Zeitpunkte der Erstellung und des Diskussionsbeginns zurückdatiert. 

BEGIN;
 UPDATE issue
   SET
     created = '2012-07-27 17:00',
     accepted = '2012-07-28 17:00',
     half_frozen = '2012-07-29 17:00'
   WHERE
     area_id in (12, 16) AND
     policy_id = 11 AND
     accepted NOTNULL AND
     half_frozen ISNULL AND
     closed ISNULL AND
     id IN (2296 , 2298);
COMMIT;

BEGIN
UPDATE 2
COMMIT

2012-07-29 ~17:00 (ib) - Einfrieren von Themen zur BuVo-Sitzung

Themen mit dem Regelwerk "Vorstandssitzung" die sich in den Themenbereichen "Vorstandssitzungen" oder "Spielwiese" befinden werden drei Tage und zwei Stunden vor der nächsten Vorstandssitzung eingefroren: 

BEGIN;
  UPDATE issue 
    SET 
      half_frozen = '2012-07-29 17:00' 
    WHERE 
      area_id in (12, 16) AND
      policy_id = 11 AND 
      accepted NOTNULL AND
      half_frozen ISNULL AND
      closed ISNULL;
COMMIT;

BEGIN
UPDATE 9
COMMIT

Dieser Schritt wird automatisch über ein Skript durchgeführt und in Zukunft nicht mehr dokumentiert.


2012-07-25 ~07:00 (ib) - Manuelles Bestätigen von E-Mail-Adressen

Einige Benutzer haben ihre E-Mail-Adresse nicht innerhalb des zulässigen Zeitfensters bestätigt. Sie haben einen manuellen Bestätigungscode an die im System hinterlegte Adresse erhalten und diesen zurückgeschickt. Die Adressen werden hiermit manuell bestätigt: 

BEGIN;
  UPDATE member
    SET notify_email = notify_email_unconfirmed, 
        notify_email_unconfirmed = NULL ,
        notify_email_secret = NULL,
        notify_email_secret_expiry = NULL,
        notify_email_lock_expiry = NULL
    WHERE id in ( ???, ???, ???, ??? ,??? );
COMMIT;

BEGIN
UPDATE 5
COMMIT

Ups, notify_email_unconfirmed wurde gelöscht bevor es in notify_email übertragen wurde. Noch mal per Hand: 

BEGIN;
  UPDATE member SET notify_email = 'XXXXXX' where id = ??? ; 
  UPDATE member SET notify_email = 'XXXXXX' where id = ??? ; 
  UPDATE member SET notify_email = 'XXXXXX' where id = ??? ; 
  UPDATE member SET notify_email = 'XXXXXX' where id = ??? ; 
  UPDATE member SET notify_email = 'XXXXXX' where id = ??? ; 
COMMIT;

BEGIN
UPDATE 1
UPDATE 1
UPDATE 1
UPDATE 1
UPDATE 1
COMMIT


2012-07-22 ~13:00 (ib) - Sperrungen

Über die Clearingstelle wurde eine Liste mit 514 zu sperrenden Einladungscodes übermittelt.

Sperren von existierenden Accounts: 

BEGIN;
  UPDATE member
  SET locked = TRUE
  WHERE id IN (
    ???,
    [...],
    ???
  );
COMMIT;

BEGIN
UPDATE 97
COMMIT

Die betroffenen Benutzer wurden per E-Mail informiert.

Entfernen von unbenutzen Einladungscodes: 

BEGIN;
  DELETE FROM invite_code
   WHERE (used ISNULL) AND (member_id ISNULL) AND (code in (
     '?????-?????-?????-?????',
     [...],
     '?????-?????-?????-?????'
  ));
COMMIT;

BEGIN
DELETE 336
COMMIT


2012-07-13 ~09:00 (ib) - Benutzer sperren und entsperren

Über die Clearingstelle wurden Listen von zu sperrenden (20) und zu entsperrenden (92) Einladungscodes übermittelt.

Sperren von Accounts: 

BEGIN;
  UPDATE member
  SET locked = TRUE
  WHERE id IN (
     ???,
     ...,
     ???
  );
COMMIT;

BEGIN
UPDATE 13
COMMIT

Entfernen nicht benutzer Einladungscodes: 

BEGIN;
  DELETE FROM invite_code
   WHERE (used ISNULL) AND (code in (
    '?????-?????-?????-?????',
    ...
    '?????-?????-?????-?????',
  ));
COMMIT;

BEGIN
DELETE 7
COMMIT

Entsperren von Accounts: 

BEGIN;
  UPDATE member
  SET locked = FALSE
  WHERE id IN (
     ???,
     ...,
     ???
  );
COMMIT;

BEGIN
UPDATE 61
COMMIT

31 weitere User waren nicht gesperrt oder hatten ihren Einladungscode noch nicht verwendet.

Die Nutzer wurden über die im System hinterlegte E-Mail-Adresse benachrichtigt.


2012-07-12 ~14:00 (ib) - Neuer Themenbereich Wissenschaft und Forschung

Erstellung eines neuen Themenbereiches für alle Initiativen zu den Themen Wissenschaft und Forschung. Die zulässigen Regelwerke entsprechen denen in anderen vergleichbaren Bereichen.

Grundlage: 


BEGIN;

  INSERT INTO area
    (
      id,
      active,
      name
    )
  VALUES
    (
      17,
      true,
      'Wissenschaft und Forschung'
    )
  ;

  INSERT INTO allowed_policy
    (
      area_id,
      policy_id,
      default_policy
    )
  VALUES
    (
      17,
      2,
      false
    ),
    (
      17,
      3,
      false
    ),
    (
      17,
      4,
      true
    ),
    (
      17,
      5,
      false
    )
  ;

COMMIT;

BEGIN
INSERT 0 1
INSERT 0 4
COMMIT


2012-07-02 ~00:30 (ib) - Thema zur Vorstandssitzung eingefroren

Das einzige offene Thema wird so eingefroren, dass die Abstimmung am Tag der Sitzung um 17 Uhr endet. 

UPDATE issue SET half_frozen = '2012-07-01 17:00' WHERE id = 2150 ;

UPDATE 1

2012-06-20 ~19:30 (ib) - Vorstandssitzungen

Anlegen eines neuen Regelwerks und eines Themenbereichs zur Vorbereitung der Bundesvorstandssitzungen. Das Regelwerk ist zum Testen auch im Sandkasten verfügbar. Das Regelwerk definiert eine sehr lange Diskussionsphase (1 Jahr) die über ein Skript jeweils rechtzeitig vor der nächsten Sitzung beendet wird, so dass die Abstimmung vor Sitzungsbeginn auslaufen. 

BEGIN;

  INSERT INTO area
    (
      id,
      active,
      name,
      description
    )
  VALUES
    (
      16,
      true,
      'Vorstandssitzungen',
      'Themenbereich  zur Vorbereitung der Vorstandssitzungen.'
    )
  ;


  INSERT INTO policy 
    (
      id,
      index,
      active,
      name,
      description,
      admission_time,
      discussion_time,
      verification_time,
      voting_time,
      issue_quorum_num,
      issue_quorum_den,
      initiative_quorum_num,
      initiative_quorum_den,
      majority_num,
      majority_den,
      majority_strict
    )
  VALUES
    (
      11,
      11,
      true,
      'Nächste Vorstandssitzung',
      'Regelwerk zur Vorbereitung der jeweils nächsten Vorstandssitzung. Achtung: Die Initiativen werden automatisch eingefroren, so dass die Abstimmungen rechtzeitig vor der Sitzung enden.',
      '3 days',
      '1 year',
      '1 day',
      '2 days',
      10,
      100,
      10,
      100,
      1,
      2,
      false
    )
  ;


  INSERT INTO allowed_policy
    (
      area_id,
      policy_id,
      default_policy
    )
  VALUES
    (
      16,
      11,
      true
    )
  ;

  INSERT INTO allowed_policy
    (
      area_id,
      policy_id,
      default_policy
    )
  VALUES
    (
      12,
      11,
      true
    )
  ;

COMMIT;

BEGIN
INSERT 0 1
INSERT 0 1
INSERT 0 1
INSERT 0 1
COMMIT

2012-05-30 ~22:00 (ib) - Sperrung von Benutzern

Durch die Umstellung der Mitgliederverwaltungssoftware kam es zur Fehlerhaften Zuordnung von Codes. Diese werden gelöscht und existierende Accounts gesperrt.

Sperrung der existierenden Accounts: 

BEGIN;
  UPDATE member
  SET locked = TRUE
  WHERE id IN (
    ???,
    ???,
    ...
    ???);
COMMIT;

BEGIN
UPDATE 339
COMMIT

Alle betroffenen Nutzer werden über die im System hinterlegte E-Mail-Adresse informiert.

Bisher nicht verwendete (aber zu sperrende Einladungscodes) werden entfernt. 

BEGIN;
 DELETE FROM invite_code
   WHERE (used ISNULL) AND (code in (
     '?????-?????-?????-?????',
     '?????-?????-?????-?????',
     ...
     '?????-?????-?????-?????'));
COMMIT;

BEGIN
DELETE 1241
COMMIT


2012-05-28 ~12:30 (ib) - Reaktivieren von Benutzern

Im Rahmen der Operation Cleanup wurden einige Mitglieder fälschlicher Weise gesperrt. Diese Personen werden jetzt über die Mitgliederverwaltung kontaktiert und successive wieder entsperrt. 

BEGIN;
  update member set locked = FALSE  where id IN ( ??? ) ;
COMMIT;

BEGIN
UPDATE 4
COMMIT

2012-05-20 ~19:00 (ib) - Delegationsverfall

Das update script core-update.v1.3.0-v1.3.1.sql setzt den Zeitstempel im Feld last_login nicht automatisch, dies wird hier manuell getan, damit der Delegationsvervall auch für Benutzer greifen kann, die sich nach dem Updatenicht mehr angemeldet haben. Zusätzlich wird sichergestellt, dass das Feld locked bei allen zur Zeit des Updates deaktivierten Benutzer gesetzt ist. 

BEGIN;
  UPDATE member SET last_login = '2012-04-06 03:03:00.0' WHERE last_login IS NULL ;
COMMIT;

sudo .../psql-wrapper.sh 05-timestamp.sql liquid_feedback_pp

BEGIN
psql:05-timestamp.sql:2: NOTICE:  word is too long to be indexed
DETAIL:  Words longer than 2047 characters are ignored.
UPDATE 5961
COMMIT

echo "SELECT id FROM member WHERE active = FALSE ;" | sudo sudo -u postgres psql liquid_feedback_pp_20120406_aspostgres

BEGIN;
 UPDATE member SET locked = TRUE WHERE id IN (...);
COMMIT;

sudo .../psql-wrapper.sh ensurelock.sql liquid_feedback_pp

BEGIN
UPDATE 1749
COMMIT

Anmerkung: Zur Zeit des Datenbankeingriffs war das Wiki down, deshalb erfolgt die Dokumentation verspätet.

2012-05-07 ~20:00 (ib) - User vom 4.5. erneut sperren

Mit der Einführung des Delegationsverfalls hat sich die Datenbankstruktur geändert. Früher gab es ein Feld 'active' welches angegeben hat, ob ein Benutzer aktiv oder gesperrt ist. Heute zeigt das Feld an, ob das Stimmrecht noch aktiv oder bereits verfallen ist. Die Sperrung eines Benutzers geschieht über das neue Feld 'locked'. Am 4. Mai habe ich (wie in der Vergangenheit) das Feld 'active' auf false gesetzt. Dies wird jedoch durch erneutes Anmelden des Benutzers wieder überschrieben. Im Folgenden wird die Sperrung korrekt durchgeführt: 

BEGIN;
  update member     set locked  = TRUE  where id = '????' ;
COMMIT;

BEGIN
UPDATE 1
COMMIT

2012-05-04 ~20:00 (ib) - Umsetzung von Nutzungsbedingungen 9.1

Einem Beschluss des Bundesvorstands folgend wurden Titel und Text einer Initiative entfernt und ein Nutzer gesperrt. 

BEGIN;
  update initiative set name    = 'Text entfernt gem. Nutzungsbedingungen 9.1' where id = 3068 ;
  update draft      set content = 'Text entfernt gem. Nutzungsbedingungen 9.1' where initiative_id = 3068 ;
  update member     set active  = FALSE  where id = '????' ;
COMMIT;

UPDATE 1
UPDATE 2
UPDATE 1

Zusätzlich Entfernung des automatisch generierten HTML Codes: 

BEGIN;
  update rendered_draft set content = 'Text entfernt gem. Nutzungsbedingungen 9.1' where draft_id = 8267 ;
  update rendered_draft set content = 'Text entfernt gem. Nutzungsbedingungen 9.1' where draft_id = 8268 ;
COMMIT;

UPDATE 1
UPDATE 1

2012-04-06 03:03 (ib) - Update Core von v1.3.0 auf v.1.3.1

Das Frontend wurde auf die letzte Version der 1.x Serie aktualisiert. Dafür wird Core 1.3.1 benötigt. Mit dem Update wird der Delegationsverfall aktiviert. Die Datenbank wurde mit pg_dump gesichert und umbenannt. Es wurde eine neue Datenbank erstellt, der neue Core eingespielt und dann die gesicherten Daten zurückgespielt. Darüber hinaus wurden keine Datenbankeingriffe durchgeführt. Während des gesamten Prozesses war das System von außen nicht erreichbar, so dass keine scheinbar erfolgreichen Nutzereingaben verloren gehen konnten. Beim Einspielen des Cores, beim Zurückspielen der Datenbankinhalte und bei den ersten Rechnungsläufen traten keine Fehler auf. Ein bekannter (in Version 2.0 gefixter Bug) wurde korrigiert.

2012-03-18 22:45 (ib) - Sperrungen für Operstion Cleanup

Grund: Die Clearingstelle hat 1606 Invite-Codes zur Sperrung übermittelt. Siehe: Blog Post

1. Ids für Deaktivierung und E-Mail/Benutzernamen für Benachrichtigung extrahieren:

Source: 

SELECT member.id, member.notify_email, member.notify_email_unconfirmed, member.name
  FROM invite_code INNER JOIN member ON (invite_code.member_id = member.id) 
  WHERE invite_code.code IN (
    'xxxxx-xxxxx-xxxxx-xxxxx',
    .
    .
    'xxxxx-xxxxx-xxxxx-xxxxx');
.
.
(1596 rows)


2. Deaktivierung der Accounts:

Source: 

BEGIN;
  UPDATE member
  SET active = FALSE
  WHERE id in (
    'XXXX',
    ...
    'XXX');
COMMIT;

$ sudo .../psql-wrapper.sh 04--deactivate_member.sql liquid_feedback_pp
.
.	
BEGIN
UPDATE 1596
COMMIT


3. Löschung der nicht verwendeter Invite-Codes:

Source: 

BEGIN;
 DELETE FROM invite_code 
   WHERE (used ISNULL) AND (code in (
     'XXXXX-XXXXX-XXXXX-XXXXX',
     ...
     'XXXXX-XXXXX-XXXXX-XXXXX'));
COMMIT;

$ sudo .../psql-wrapper.sh 05--delete_invalid_invites_wrapper.sql liquid_feedback_pp
.
.
BEGIN
DELETE 10
COMMIT

Die Benutzer wurden per E-Mail informiert. Die Profildaten werden in naher Zukunft gelöscht.

Abgerufen von „https://wiki.piratenpartei.de/wiki/index.php?title=LQPP/Datenbankeingriffe&oldid=2200455“