Я не хотел писать ORM для Kotlin/Native. Мне просто нужен был PostgreSQL

[DaniilsLoputevs]

Почему не Exposed? Он же вроде multiplatform?

Читая статью, у меня тоже висел этот вопрос. Exposed действительно круто выглядит, но с Kotlin/Native (и полноценным KMP) там пока всё грустно :(

В чём проблема:

• Библиотека сильно завязана на Java-код. Там полно java.sql.*, BigDecimal, UUID, java.time, ConcurrentHashMap, ByteBuffer и прочих JVM-only штук.

• В DAO-модуле очень тяжело используется reflection — а в Native reflection сильно урезанный, поэтому многие фичи просто не взлетят.

• Нет единого драйвера под Muliplatform. На JVM есть JDBC, а для Native + Android + iOS нужно отдельно городить поддержку SQLite и всего остального — это отдельная большая история.

В JB знают этот запрос и потихоньку его решают (переводят core модуль на multiplatform), но это не приоритер сейчас и ближайшее будущее.

Полезные ссылки по этому вопросы:

1. Главный GitHub issue (открыт с 2019 года) — https://github.com/JetBrains/Exposed/issues/635

2. YouTrack-трекер по KMP-поддержке — https://youtrack.jetbrains.com/issue/EXPOSED-767

3. PR с переводом exposed-core на KMP — https://github.com/JetBrains/Exposed/pull/2629 (там очень подробный комментарий от команды)

[onets]

Кубернетс для геологов? Звучит как оверинжиниринг.

[DaniilsLoputevs]

Почему вы так думаете?

[onets]

Потому что кубернетс сделали в Гугле, чтобы управлять своей флотилией серверов. Вряд ли автор работает в Гугле

Можно конечно настроить кубернетс для своих 1.5 микросервиса, но это как из пушки по воробьям. Кубернетс сам по себе - сложная штука. А даже простой переход на докеры - это кратный рост затрат на инфраструктуру и зарплаты дев опсов.

[cmyser]

Для веб сервачка лучше бы go подошел, там и инфраструктура есть и бинарь

[DaniilsLoputevs]

Это другой язык с другой философии и экосистемой и это сложное и дороже в плане попробовать и если удачно, то развивать

В этом и есть прелесть Kotlin Native, всё своё и родное. Понятно и знакомо как попробовать и если понадобится развивать, то не придётся переезжать на другой ЯП

П.с. чисто имхо - я поработал с Go и он мне не понравился, особенно после Kotlin

[navrocky]

Спасибо за либу, буду тянуть её в свой проект на K/N. Тоже давно искал что-то нормальное для работы с БД, тоже хотел писать своё, но теперь видимо и не надо )

Единственное что меня смущает так это двойное дублирование сущности в коде:

object Users : Table<MainCatalog, User>("users", ::User) {    
    val id by Column.Long().primaryKey()    
    val name by Column.Text()    
    val email by Column.Text()    
    val age by Column.Int()    
}    
class User : Entity() {    
    var id by Users.id    
    var name by Users.name    
    var email by Users.email    
    var age by Users.age    
}   

Это дублирование ещё усугубляется тем что у меня в Core слое тоже есть сущность User и для REST API есть UserDto... Вот что с этим делать?

Можно ли как-то обойтись одной Entity/Table а не двумя, надеюсь моя мысль понятна?