Я использую Java для создания спокойного API на основе функций интеграции данных Pentaho.
Я реализовал несколько конечных точек, таких как возможность создания репозитория содержащие задания и преобразования, выполнение заданий и преобразований, отображение изображения задания и преобразований, отображение соединений с базой данных в репо, а также многое другое.
Я пытаюсь создать конечную точку, которая позволяет изменять источники данных, такие как имя хоста, имя базы данных и т. д. Но я столкнулся с проблемой, когда дело доходит до сохранения новых деталей подключения.
Вот фрагмент кода, который у меня есть. Я жестко запрограммировал значения просто для тестирования. Я просматриваю список массивов, содержащий DatabaseMeta, а затем меняю значения полей.
for(DatabaseMeta meta: databaseMeta) {
meta.setHostName(“test_host”) ;
meta.setDBPort(“test_port”);
meta.setDBName(“test_database”);
repositoryService.updateDataSource(databaseMeta);
}
Метод updateDatasource () просто вызывает repository.save () (который является частью пакета org.pentaho.di.repository) и передает DatabaseMeta.
Когда этот метод выполняется, он создает файл .kdb в моем репозитории со значениями, которые я установил выше, и выполнение запроса GET к конечной точке возвращает сведения о соединении из нового файла. Однако я просто хочу перезаписать значения в существующем соединении преобразования и вернуть их в запросе GET. Можно ли как-нибудь достичь этого? Любая помощь будет оценена.
Спасибо.
Итак, вы хотите получать значений нового соединения без создания нового .kdb в репозитории?
Я знаю о Carte, но компания, в которой я работаю, хочет, как вы говорите, «изобретать велосипед».
Да, я хочу иметь возможность хранить новые данные о подключении в существующем .ktr, а затем иметь возможность получать их в запросе GET, не создавая новый .kdb в репозитории. Это возможно? Я ломал голову 3 дня, пытаясь решить эту проблему.
Я так не думаю. UpdateDatasource, который является обязательным, автоматически создаст новый .kdb. Однако вы можете создать новый источник данных tmp, который впоследствии удалите.




Просто чтобы убедиться, что вы не изобретаете велосипед: (1) знаете ли вы о создании веб-API вокруг PDI? (2) вы знаете файл чайник.properties?