различать «create, fail if exists» и «getOrCreate» операции?
Допустим, есть такой DSL для описания структуры таблиц (мне оно для тестов):
tables {
table("users") {
column("id")
// …
}
}
Выглядит, работает, всё устраивает. Но есть нюанс: если нужно не создать, а обновить таблицу (скажем, добавить колонку), то table("users") упадёт со словами «таблица users уже объявлена». В целом, логично, что нечего объявлять двух таблиц с одинаковыми названиями, и это, вроде как, может уберечь от copy-paste ошибок.
Есть принятые подходы в подобных случаях?
Плодить existingTable(…), existingColumn(..)?
Добавлять какой-то top-level режим «mode=FAIL_ON_DUPLICATE | MERGE_ON_DUPLICATE»?
Переписать реализацию, чтобы table(…) выполняло именно getOrCreate?
зачем top-level mode? можно же сделать опциональный именовынный параметр в table и column fun table(failOnExist : Boolean = false,codeblock:()->Unit) { if(failOnExist) { print("fail") } else { codeblock() } } fun main() { table { print("ok") } }
я думаю, можно сделать и так, и так чтобы если что для каждого тру не вписывать
а если оно дсл для структуры то зачем оно само что-то создает, ну во всяком случае я бы вот отделил собственно датабейз операции от определения структуры, как это примерно везде сделано, и для создания и для миграций же свой механизм, которому структура только параметр, причем миграция сложнее "переименовать табличку" обычно сырой sql, упаковывая все это в бэк структуры описания можно и поседеть
А есть примеры, где такое встречается? Мне почему-то вспоминается maven с его combine.self и combine.children А вот Kotlin примеров не помню. Большинство builder’ов в режиме append-only.
Обсуждают сегодня