Как я могу сообщить PostgreSQL о том, чтобы не прервать всю транзакцию, когда одно ограничение завершилось неудачей?

Ответ 1

Я очень новичок в PostgreSQL, но один из примеров в документации PostgreSQL для программирования триггеров/серверов выглядит так, как будто он делает именно то, что вы ищете.

Смотрите: http://www.postgresql.org/docs/9.2/static/trigger-example.html

Фрагмент со страницы: "Таким образом, триггер действует как непустое ограничение, но не прерывает транзакцию".

Ответ 2

Я бы настоятельно предложил SqlAlchemy и использовать субтранзакции. Вы можете указать код:

#some code 
Session.begin(subtransactions=True)
#more stuff including sql activity then:
with Session.begin(nested=True):
    # get the security
    try:
       foo = MyCodeToMakeFOO(args)
       Session.add(foo)
       Session.flush()
    except:
       log.error("Database hated your foo(%s) but I'll do the rest"%foo)

Наиболее полезно, когда субтранзакция находится в цикле, где вы хотите обработать хорошие записи и записать плохие.

Ответ 3

Я знаю, что это очень старый билет, но (по состоянию на 2017 год) PostgreSQL по-прежнему имеет такое же поведение автоматического откат себя, когда что-то пойдет не так в фиксации. Я хотел бы поделиться некоторыми мыслями здесь.

Я не знаю, можем ли мы изменить это поведение, и мне это не нужно, возможно, для лучшего делегирования PostgreSQL для управления откатом для нас (он знает, что он делает, верно?). Откат назад означает изменение данных до исходного состояния до неудачной транзакции, что означает, что измененные или вставленные данные из триггеров также будут отброшены. В логике ACID это то, что мы хотим. Скажем, вы сами управляете откатом на внутреннем сервере, если что-то пойдет не так во время вашего отката или если база данных будет изменена одновременно с внешними транзакциями во время вашего отката, данные станут непоследовательными, а вся ваша структура, скорее всего, коллапс.

Итак, зная, что PostgreSQL будет управлять своей собственной стратегией отката, вопрос, который нужно задать, "как я могу расширить стратегию отката?" . То, о чем вы сначала подумали, , что привело к сбою транзакции?. В своей структуре try/catch попытайтесь обработать все возможные исключения и снова запустить транзакцию или отправить обратную связь в интерфейсное приложение с некоторыми соответствующими сообщениями "не делать". Для меня это лучший способ обработки вещей, это меньше кода, меньше накладных расходов, большего контроля, более удобного для пользователя, и ваша база данных будет вам благодарна.

Последняя точка, которую я хочу пролить, стандарт SQL имеет код sqlstate, который может использоваться для связи с внутренними модулями. Неисправная операция во время транзакции вернет код sqlstate, и вы сможете использовать эти коды для устранения недостатков. Вы можете создавать свои собственные коды sqlstate, если они не работают с зарезервированными (https://www.postgresql.org/message-id/20185.1359219138%40sss.pgh.pa.us). Например, в функции plpgsql

...
$$
begin
...do something...if it goes wrong
raise exception 'custom exception message' using errcode='12345';
end
$$
...

Это пример использования PDO в PHP (с использованием кода ошибки выше):

...
$pdo->beginTransaction();
try {
  $s = $pdo->prepare('...');
  $s->execute([$value]);

  /**
   * Simulate a null violation exception
   * If it fails, PDO will not wait the commit
   * and will throw the exception, the code below
   * is not executed.
   */
  $s->execute([null]);

  /**
   * If nothing wrong happened, we commit to change
   * the database state.
   */
  $pdo->commit();
}
catch (PDOException $e) {
  /**
   * It is important to also have the commit here.
   * It will trigger PostgreSQL rollback.
   * And make the pdo Object back to auto-commit mode.
   */
  $pdo->commit();

  if ($e->getCode() === '12345') {
    send_feedback_to_client('please do not hack us.');
  }
}
...