PDI: возврат результата оператора SELECT в поток данных

Используя PDI (Kettle) я заполняю начальный этап своей базы данных, используя шаги CSV Inputи Table Output. Это прекрасно работает, однако я также хочу убедиться, что только что вставленные данные соответствуют определенным критериям, например. поля, не равные NULL, и т. д.

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

Именно для этого я написал несколько операторов SELECT Count(*) as test123 ..., которые мгновенно показывают, что что-то не так, и с которыми легко работать (если значение test123 равно 0, все в порядке, иначе задание нужно прервать).

Я выполняю эти инструкции, используя шаг Execute SQL Statements в преобразовании PDI. Я ожидал, что результат будет автоматически передан в мой поток данных, поэтому я также использовал шаг Copy rows to result, чтобы передать его выполняющемуся заданию.

Это точка, где проблема, скорее всего, находится. Я думаю, что результат оператора SELECT не был автоматически передан в мой поток данных, потому что, когда я выполняю Simple evaluation в основном задании, используя переменную ${test123} (которая, как я думал, будет неявно создана при выполнении SELECT Count(*) as test123 ...), я никогда не получаю ожидаемого результата.

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

с уважением

Изменить: это простая модель моей основной работы:

Пуск --> Загрузить данные (преобразование) --> Проверить данные (преобразование) --> Простая оценка --> ...


person daZza    schedule 27.08.2014    source источник
comment
Итак, вы делаете эти операторы SQL в преобразовании, когда поток данных поступает из задания, или проверяете его, подключаясь к вашей базе данных?   -  person Seb    schedule 27.08.2014
comment
Шаг Execute SQL Statements подключается к базе данных и выполняет оператор. Это делается в отдельном преобразовании, которое вызывается заданием.   -  person daZza    schedule 27.08.2014
comment
SQL обязателен? Как насчет шага JavaScript в вашей проверке преобразования данных?   -  person Seb    schedule 27.08.2014
comment
Что в этом случае сделает JavaScript? Мне нужно запросить мои данные, чтобы увидеть, в порядке ли они или нет   -  person daZza    schedule 27.08.2014
comment
ок, извини. Я думал, что ваши данные уже есть. Как идея: возможно, вам нужно сгенерировать пустую строку с именем test123 перед sql-шагом   -  person Seb    schedule 27.08.2014
comment
а что, если вы проверите входящие данные вашего sql-шага с выбранными значениями? какие строки отображаются. Я могу представить, что у пентахо проблемы с обнаружением ваших новых строк.   -  person Seb    schedule 27.08.2014
comment
Что ж, данные есть. Но я не могу быть уверен, что это тоже правильно (отсюда и проверочное преобразование данных)   -  person daZza    schedule 27.08.2014
comment
Когда я пытаюсь выбрать его с помощью Select values, PDI выдает ошибку: Couldn't find field '${test123}' in row!, которая, кажется, подтверждает мое мнение о том, что результаты не автоматически помещаются в поток данных.   -  person daZza    schedule 27.08.2014
comment
да. Вы установили флажок с переменными в своем sql-шаге? для этого должен быть флажок. если это не главное: что происходит, если нажать кнопку «Получить поля» на шаге «Выбор значений»? Ничего такого? Затем попробуйте этот упомянутый шаг «Создать строки», чтобы PDI знал новую строку. Надеюсь, поможет   -  person Seb    schedule 27.08.2014
comment
Вы имеете в виду флажок подстановки переменных? Нет, я этого не проверял, потому что я не заменяю никакие переменные в своем скрипте. Когда я нажимаю кнопку «Получить поля», вообще ничего не происходит. Я попробую шаг генерации строк, может быть, это поможет. Редактировать: Нет, никаких изменений при его использовании.   -  person daZza    schedule 27.08.2014
comment
ммч. ваше преобразование должно начинаться с создания строк, где вы определяете test123 как новое поле (строку) 2step - это ваш sql с вашим оператором, выберите... AS 'test123' 3step - это выбор значений, нажмите на поля get, чтобы вывести test123 как поле или, может быть, два поля test123 и test123_1 (я знаю это из html-шага, который я использую)   -  person Seb    schedule 27.08.2014
comment
новая идея: сделайте шаг ввода таблицы вместо шага выполнения sql, здесь вам не нужно генерировать строки   -  person Seb    schedule 27.08.2014
comment
Давайте продолжим обсуждение в чате.   -  person Seb    schedule 27.08.2014


Ответы (1)


Вы смешиваете несколько понятий, если я правильно прочитал ваш пост.

  1. Вам не нужен скрипт Execute SQL, это задание для шага ввода таблицы. Просто введите свой запрос в поле «Таблица», и вы сможете просмотреть свои данные и увидеть, как они поступают с шага в поток данных, используя предварительный просмотр на следующем шаге. Сценарий «Выполнение SQL» не является шагом ввода, что означает, что он не будет добавлять внешние данные в ваш поток данных.

  2. Поля вывода не являются переменными. Переменная задается с помощью шага «Установить переменные», который берет одну входную строку и сопоставляет конкретное поле с переменной, которая может сохраняться на уровне родительского или корневого задания. Поля — это просто поля. Они передаются от одного шага к другому через переходы и, в конечном итоге, к родительскому заданию, если у вас есть шаг Копировать строки в результат, но они НЕ являются переменными.

person nsousa    schedule 28.08.2014