Подтвердить что ты не робот

Использование getGeneratedKeys с пакетными вставками в MySQL с помощью Connector/J

Используя Connector/J, я хотел бы сделать пакетную вставку в главную таблицу, за которой следует вставка пакета в таблицу подробностей (PreparedStatement.executeBatch() для обоих). Я не нашел много информации в Интернете, поэтому я ищу любую обратную связь от людей, которые имеют опыт работы с этим.

  • Могу ли я использовать Statement.getGeneratedKeys(), чтобы получить идентификаторы вновь вставленных строк в главной таблице, чтобы я мог использовать их как внешние ключи в подробные вставки?

  • Что делать, если не каждый запрос привел к вставка (например, был запрос insert ignore или insert ... on duplicate key update)? Я получу ряд в Statement.getGeneratedKeys() для каждого или только для новых?

  • Что будет Statement.getGeneratedKeys() возврат есть ошибка с одним из вставленные основные записи и continueBatchOnError установлено значение true в строке соединения?

  • Существуют ли различия в отношении поведения между версиями Connector/J версии 5.0.x vs 5.5.x? Что относительно MySQL 5.0 против 5.1?

  • Есть ли какие-либо другие проблемы или ошибки, о которых я должен знать?

  • Есть ли лучший способ сделать это?

4b9b3361

Ответ 1

Хорошо, я провел несколько тестов. С Connector/J 5.1 и MySQL 5.1.42 я наблюдаю следующее:

  • Statement.getGeneratedKeys() работает как ожидалось для вставок

  • Если строка была вставлена ​​или обновлена ​​(массив count update, возвращаемый executeBatch(), возвращает "1" или "2" ), Statement.getGeneratedKeys() будет иметь ключ для этой строки. Если строка не была изменена (insert ignore или insert ... on duplicate key update, что приводит к отсутствию-op, executeBatch() возвращает 3), ключа нет.

  • ResultSet, возвращаемый getGeneratedKeys, будет содержать записи для успешно вставленных строк в соответствии с (2). Не будет сгенерированной строки ключа для неудачных вставок (где значение подсчета обновлений Statement.EXECUTE_FAILED)

  • Будьте осторожны с rewriteBatchedStatements в строке подключения JDBC. Если он установлен в true, любые сбои приведут к тому, что каждая строка в переписанном "куске" будет обработана так, как если бы она потерпела неудачу. Один из способов справиться с этим - перебрать неудавшиеся строки и повторить их без пакетной обработки.