Une question très fréquemment posée ici est de savoir comment faire un upsert, ce que MySQL appelle INSERT ... ON DUPLICATE UPDATEet la norme prend en charge dans le cadre de l' MERGEopération.

Étant donné que PostgreSQL ne le prend pas directement en charge (avant la page 9.5), comment procédez-vous? Considérer ce qui suit:

CREATE TABLE testtable (
    id integer PRIMARY KEY,
    somedata text NOT NULL
);

INSERT INTO testtable (id, somedata) VALUES
(1, 'fred'),
(2, 'bob');

Maintenant , imaginez que vous voulez « upsert » les tuples (2, 'Joe'), (3, 'Alan'), de sorte que le nouveau contenu de la table serait:

(1, 'fred'),
(2, 'Joe'),    -- Changed value of existing tuple
(3, 'Alan')    -- Added new tuple

C'est de cela que les gens parlent lorsqu'ils discutent d'un upsert. Surtout, toute approche doit être sûre en présence de plusieurs transactions travaillant sur la même table - soit en utilisant un verrouillage explicite, soit en se défendant contre les conditions de concurrence qui en résultent.

Ce sujet est abordé en détail dans Insert, sur la mise à jour en double dans PostgreSQL? , mais il s'agit d'alternatives à la syntaxe MySQL, et elle a augmenté un peu de détails non liés au fil du temps. Je travaille sur des réponses définitives.

Ces techniques sont également utiles pour "insérer s'il n'existe pas, sinon ne rien faire", c'est-à-dire "insérer ... sur une clé en double ignorer".

9.5 et plus récent:

PostgreSQL 9.5 et support plus récent INSERT ... ON CONFLICT UPDATE(et ON CONFLICT DO NOTHING), ie upsert.

Comparaison avecON DUPLICATE KEY UPDATE .

Explication rapide .

Pour l'utilisation, voir le manuel - en particulier la clause conflict_action dans le diagramme de syntaxe et le texte explicatif .

Contrairement aux solutions pour 9.4 et antérieures présentées ci-dessous, cette fonctionnalité fonctionne avec plusieurs lignes en conflit et ne nécessite pas de verrouillage exclusif ni de boucle de relance.

Le commit ajoutant la fonctionnalité est ici et la discussion autour de son développement est ici .

Si vous êtes sur 9.5 et n'avez pas besoin d'être rétrocompatible, vous pouvez arrêter la lecture maintenant .

9.4 et plus:

PostgreSQL n'a pas de fonction intégrée UPSERT(ou MERGE), et le faire efficacement face à une utilisation simultanée est très difficile.

Cet article décrit le problème en détail utile .

En général, vous devez choisir entre deux options:

• Opérations d'insertion / mise à jour individuelles dans une boucle de nouvelle tentative; ou
• Verrouillage de la table et fusion par lots

Boucle de relance de ligne individuelle

L'utilisation de sauts de ligne individuels dans une boucle de nouvelle tentative est l'option raisonnable si vous souhaitez que de nombreuses connexions essaient simultanément d'effectuer des insertions.

La documentation PostgreSQL contient une procédure utile qui vous permettra de le faire en boucle à l'intérieur de la base de données . Il protège contre les mises à jour perdues et les courses d'insertion, contrairement à la plupart des solutions naïves. Cela ne fonctionnera qu'en READ COMMITTEDmode et n'est sûr que si c'est la seule chose que vous faites dans la transaction. La fonction ne fonctionnera pas correctement si les déclencheurs ou les clés uniques secondaires provoquent des violations uniques.

Cette stratégie est très inefficace. Dans la mesure du possible, vous devez mettre le travail en file d'attente et effectuer une mise à jour groupée comme décrit ci-dessous.

De nombreuses tentatives de solutions à ce problème ne prennent pas en compte les annulations, elles entraînent donc des mises à jour incomplètes. Deux transactions se font la course; l'un d'eux a réussi INSERTs; l'autre obtient une erreur de clé en double et fait à la UPDATEplace. Les UPDATEblocs en attente INSERTde restauration ou de validation. Lorsqu'elle est annulée, la UPDATEnouvelle vérification de la condition correspond à zéro ligne, donc même si UPDATEles validations n'ont pas réellement fait l'upert que vous attendiez. Vous devez vérifier le nombre de lignes de résultats et réessayer si nécessaire.

Certaines solutions tentées ne tiennent pas compte non plus des races SELECT. Si vous essayez l'évidence et la simplicité:

-- THIS IS WRONG. DO NOT COPY IT. It's an EXAMPLE.

BEGIN;

UPDATE testtable
SET somedata = 'blah'
WHERE id = 2;

-- Remember, this is WRONG. Do NOT COPY IT.

INSERT INTO testtable (id, somedata)
SELECT 2, 'blah'
WHERE NOT EXISTS (SELECT 1 FROM testtable WHERE testtable.id = 2);

COMMIT;

puis, lorsque deux fonctionnent en même temps, il existe plusieurs modes de défaillance. L'un est le problème déjà discuté avec une nouvelle vérification de la mise à jour. Un autre est où les deux UPDATEen même temps, correspondant à zéro ligne et continuant. Ensuite, ils font tous les deux le EXISTStest, qui a lieu avant le INSERT. Les deux obtiennent zéro ligne, donc les deux font le INSERT. Un échoue avec une erreur de clé en double.

C'est pourquoi vous avez besoin d'une boucle de réessai. Vous pourriez penser que vous pouvez éviter les erreurs de clé en double ou les mises à jour perdues avec SQL intelligent, mais vous ne pouvez pas. Vous devez vérifier le nombre de lignes ou gérer les erreurs de clé en double (selon l'approche choisie) et réessayer.

Veuillez ne pas lancer votre propre solution pour cela. Comme pour la mise en file d'attente des messages, c'est probablement faux.

Upsert en vrac avec serrure

Parfois, vous souhaitez effectuer une mise à niveau groupée, dans laquelle vous disposez d'un nouvel ensemble de données que vous souhaitez fusionner avec un ancien ensemble de données existant. Ceci est beaucoup plus efficace que les sauts de rangs individuels et devrait être préféré chaque fois que cela est possible.

Dans ce cas, vous suivez généralement le processus suivant:

• CREATEune TEMPORARYtable

• COPY ou insérez en masse les nouvelles données dans la table temporaire

• LOCKla table cible IN EXCLUSIVE MODE. Cela permet à d'autres transactions SELECT, mais sans apporter de modifications à la table.

• Faites un UPDATE ... FROMdes enregistrements existants en utilisant les valeurs de la table temporaire;

• Faites une INSERTdes lignes qui n'existent pas déjà dans la table cible;

• COMMIT, libérant le verrou.

Par exemple, pour l'exemple donné dans la question, en utilisant plusieurs valeurs INSERTpour remplir la table temporaire:

BEGIN;

CREATE TEMPORARY TABLE newvals(id integer, somedata text);

INSERT INTO newvals(id, somedata) VALUES (2, 'Joe'), (3, 'Alan');

LOCK TABLE testtable IN EXCLUSIVE MODE;

UPDATE testtable
SET somedata = newvals.somedata
FROM newvals
WHERE newvals.id = testtable.id;

INSERT INTO testtable
SELECT newvals.id, newvals.somedata
FROM newvals
LEFT OUTER JOIN testtable ON (testtable.id = newvals.id)
WHERE testtable.id IS NULL;

COMMIT;

Lecture connexe

• Page wiki UPSERT
• UPSERTismes dans Postgres
• Insérer, lors d'une mise à jour en double dans PostgreSQL?
• http://petereisentrara.blogspot.com/2010/05/merge-syntax.html
• Renoncer à une transaction
• SELECT ou INSERT est-il dans une fonction sujette aux conditions de course?
• SQL MERGEsur le wiki PostgreSQL
• Le moyen le plus idiomatique pour implémenter UPSERT dans Postgresql de nos jours

Et alors MERGE?

Le standard SQL MERGEa en fait une sémantique de concurrence d'accès mal définie et ne convient pas pour la mise à jour sans verrouiller d'abord une table.

C'est une instruction OLAP vraiment utile pour la fusion de données, mais ce n'est pas en fait une solution utile pour l'upsert concurrentiel sécurisé. Il y a beaucoup de conseils aux personnes utilisant d'autres SGBD MERGEpour les upserts, mais c'est en fait faux.

Autres DB:

• INSERT ... ON DUPLICATE KEY UPDATE dans MySQL
• MERGEde MS SQL Server (mais voir ci-dessus les MERGEproblèmes)
• MERGEd'Oracle (mais voir ci-dessus à propos des MERGEproblèmes)

J'essaie de contribuer avec une autre solution pour le problème d'insertion unique avec les versions antérieures à 9.5 de PostgreSQL. L'idée est simplement d'essayer d'effectuer d'abord l'insertion, et dans le cas où l'enregistrement est déjà présent, de le mettre à jour:

do $$
begin 
  insert into testtable(id, somedata) values(2,'Joe');
exception when unique_violation then
  update testtable set somedata = 'Joe' where id = 2;
end $$;

Notez que cette solution ne peut être appliquée que s'il n'y a aucune suppression de lignes de la table .

Je ne connais pas l'efficacité de cette solution, mais elle me semble assez raisonnable.

Voici quelques exemples pour insert ... on conflict ...( pg 9.5+ ):

• Insérer, en cas de conflit - ne rien faire .

  insert into dummy(id, name, size) values(1, 'new_name', 3)
  on conflict do nothing;`  

• Insérer, en cas de conflit - mettre à jour , spécifier la cible du conflit via la colonne .

  insert into dummy(id, name, size) values(1, 'new_name', 3)
  on conflict(id)
  do update set name = 'new_name', size = 3;  

• Insérer, en cas de conflit - mettre à jour , spécifier la cible du conflit via le nom de la contrainte .

  insert into dummy(id, name, size) values(1, 'new_name', 3)
  on conflict on constraint dummy_pkey
  do update set name = 'new_name', size = 4;

SQLAlchemy upsert pour Postgres> = 9.5

Étant donné que le grand message ci-dessus couvre de nombreuses approches SQL différentes pour les versions de Postgres (non seulement non-9.5 comme dans la question), je voudrais ajouter comment le faire dans SQLAlchemy si vous utilisez Postgres 9.5. Au lieu d'implémenter votre propre upsert, vous pouvez également utiliser les fonctions de SQLAlchemy (qui ont été ajoutées dans SQLAlchemy 1.1). Personnellement, je recommanderais de les utiliser si possible. Non seulement pour des raisons de commodité, mais aussi parce qu'il permet à PostgreSQL de gérer toutes les conditions de concurrence qui pourraient se produire.

Publication croisée d'une autre réponse que j'ai donnée hier ( https://stackoverflow.com/a/44395983/2156909 )

SQLAlchemy prend ON CONFLICTdésormais en charge deux méthodes on_conflict_do_update()et on_conflict_do_nothing():

Copie de la documentation:

from sqlalchemy.dialects.postgresql import insert

stmt = insert(my_table).values(user_email='a@b.com', data='inserted data')
stmt = stmt.on_conflict_do_update(
    index_elements=[my_table.c.user_email],
    index_where=my_table.c.user_email.like('%@gmail.com'),
    set_=dict(data=stmt.excluded.data)
    )
conn.execute(stmt)

http://docs.sqlalchemy.org/en/latest/dialects/postgresql.html?highlight=conflict#insert-on-conflict-upsert

WITH UPD AS (UPDATE TEST_TABLE SET SOME_DATA = 'Joe' WHERE ID = 2 
RETURNING ID),
INS AS (SELECT '2', 'Joe' WHERE NOT EXISTS (SELECT * FROM UPD))
INSERT INTO TEST_TABLE(ID, SOME_DATA) SELECT * FROM INS

Testé sur Postgresql 9.3

Depuis que cette question a été fermée, je poste ici pour savoir comment vous le faites en utilisant SQLAlchemy. Par récursivité, il réessaye une insertion en masse ou une mise à jour pour lutter contre les conditions de course et les erreurs de validation.

D'abord les importations

import itertools as it

from functools import partial
from operator import itemgetter

from sqlalchemy.exc import IntegrityError
from app import session
from models import Posts

Maintenant, quelques fonctions d'assistance

def chunk(content, chunksize=None):
    """Groups data into chunks each with (at most) `chunksize` items.
    https://stackoverflow.com/a/22919323/408556
    """
    if chunksize:
        i = iter(content)
        generator = (list(it.islice(i, chunksize)) for _ in it.count())
    else:
        generator = iter([content])

    return it.takewhile(bool, generator)


def gen_resources(records):
    """Yields a dictionary if the record's id already exists, a row object 
    otherwise.
    """
    ids = {item[0] for item in session.query(Posts.id)}

    for record in records:
        is_row = hasattr(record, 'to_dict')

        if is_row and record.id in ids:
            # It's a row but the id already exists, so we need to convert it 
            # to a dict that updates the existing record. Since it is duplicate,
            # also yield True
            yield record.to_dict(), True
        elif is_row:
            # It's a row and the id doesn't exist, so no conversion needed. 
            # Since it's not a duplicate, also yield False
            yield record, False
        elif record['id'] in ids:
            # It's a dict and the id already exists, so no conversion needed. 
            # Since it is duplicate, also yield True
            yield record, True
        else:
            # It's a dict and the id doesn't exist, so we need to convert it. 
            # Since it's not a duplicate, also yield False
            yield Posts(**record), False

Et enfin la fonction upsert

def upsert(data, chunksize=None):
    for records in chunk(data, chunksize):
        resources = gen_resources(records)
        sorted_resources = sorted(resources, key=itemgetter(1))

        for dupe, group in it.groupby(sorted_resources, itemgetter(1)):
            items = [g[0] for g in group]

            if dupe:
                _upsert = partial(session.bulk_update_mappings, Posts)
            else:
                _upsert = session.add_all

            try:
                _upsert(items)
                session.commit()
            except IntegrityError:
                # A record was added or deleted after we checked, so retry
                # 
                # modify accordingly by adding additional exceptions, e.g.,
                # except (IntegrityError, ValidationError, ValueError)
                db.session.rollback()
                upsert(items)
            except Exception as e:
                # Some other error occurred so reduce chunksize to isolate the 
                # offending row(s)
                db.session.rollback()
                num_items = len(items)

                if num_items > 1:
                    upsert(items, num_items // 2)
                else:
                    print('Error adding record {}'.format(items[0]))

Voici comment vous l'utilisez

>>> data = [
...     {'id': 1, 'text': 'updated post1'}, 
...     {'id': 5, 'text': 'updated post5'}, 
...     {'id': 1000, 'text': 'new post1000'}]
... 
>>> upsert(data)

L'avantage que cela présente bulk_save_objectsest qu'il peut gérer les relations, la vérification des erreurs, etc. lors de l'insertion (contrairement aux opérations en bloc ).