@kotlin_lang
Igor14.02.2018
07:49:00
07:49:00
Да у тебя там же бизнес-логика небось
Нет, агрегирование сущностей и версионирование + выделение метаданных и два-три кейса агрегирование коллекций по хитрым правилам, вписывающихся в логику работы с данными. В DSL я бы это НЕ написал, ибо там есть View и на 100, и на 200, и на 400 строк
Igor14.02.2018
07:51:15
07:51:15
Ну значит ты молодец, но сам подходе не мешает ее туда засунуть типа “временно” (сроки поджимали и тд) и оставить ее там на всегда
Руслан14.02.2018
07:54:11
07:54:11
> хранимки
Вот это печально, что мы уходим с уровня кода в базу, теряя все преймущества своих языков
в postgres еще rest вроде есть (или есть расширение позволяющее работать без прослойки на сервере с базой) ?Igor14.02.2018
07:54:46
07:54:46
Да там еще и хранимки можно на java / javascript писать ?
Это же можно postgres-процедурки на Kotlin писать и в JS компилить ?
GoogleIgor14.02.2018
07:56:55
07:56:55
Ну значит ты молодец, но сам подходе не мешает ее туда засунуть типа “временно” (сроки поджимали и тд) и оставить ее там на всегда
К счастью, это стартапик формата пет-проекта, который я вечерами делаю, так что везде все строго :) А так – да, согласен, иногда может и потребоваться срочно что-то сделать.Igor14.02.2018
08:11:04
08:11:04
в postgres еще rest вроде есть (или есть расширение позволяющее работать без прослойки на сервере с базой) ?
Это можно как в докладе “Николай Рыжиков — JS внутри PostgreSQL”
целый сервер написать на Kotlin внутри postgress
Phil14.02.2018
08:14:40
08:14:40
Можно тогда спросить: "Зачем делать абстракции?" Я вот не считаю что SQL удобный, но знать его приходится, потому что абстракции не идеальны.
Вот у меня в ORM есть такой запрос:
val candidates = ObjectSelect.query(Candidate::class.java)
.where(Candidate.EMAIL.likeIgnoreCase(dbQuery))
.or(Candidate.COMPANY.likeIgnoreCase(dbQuery))
.or(Candidate.FIRST_NAME.likeIgnoreCase(dbQuery))
.or(Candidate.LAST_NAME.likeIgnoreCase(dbQuery))
.or(Candidate.PHONE.likeIgnoreCase(dbQuery))
.or(Candidate.PHONE2.likeIgnoreCase(dbQuery))
.or(Candidate.STATUS.likeIgnoreCase(dbQuery))
.or(Candidate.TAGS.dot(CandidateTag.NAME).likeIgnoreCase(dbQuery))
.offset(serviceConfiguration.pageSize * (page - 1))
.limit(serviceConfiguration.pageSize)
.orderByProp(Candidate.ID_PK_COLUMN)
.select(context)
.map { it.toDto() }
неужели он может выглядеть понятнее на SQL? как мне оформлять код, следить за типо безопасностью (и безопасностью типов :) )?
Ну, скорее всего в таком виде запросы лучше вообще не писать, or для СУБД вредная операция. Но вообще на SQL он был бы раз в пять короче и очевиднее )Руслан14.02.2018
08:16:20
08:16:20
Ну, скорее всего в таком виде запросы лучше вообще не писать, or для СУБД вредная операция. Но вообще на SQL он был бы раз в пять короче и очевиднее )
Ну окей, запрос короче. А теперь его нужно замапить обратно на объект, прикрутить кешик, и т.д. Сколько теперь будет кода? И зачем мне его самому писатьPhil14.02.2018
08:17:39
08:17:39
Ну и все обертки сильно уменьшают возможности, увы. Благо в современных СУБД хватает интересных вещей - от эффективной работы с Jason (что, зачастую, вообще делает orm не нужен) до оконных функций и массивов.
Руслан14.02.2018
08:18:34
08:18:34
Ну и все обертки сильно уменьшают возможности, увы. Благо в современных СУБД хватает интересных вещей - от эффективной работы с Jason (что, зачастую, вообще делает orm не нужен) до оконных функций и массивов.
Ну это замечательно, но не решает описанные выше проблем: маппинг на объекты, типо-безопасные запросы, кэшPhil14.02.2018
08:19:14
08:19:14
Ну окей, запрос короче. А теперь его нужно замапить обратно на объект, прикрутить кешик, и т.д. Сколько теперь будет кода? И зачем мне его самому писать
Замапить - это одна простая функция на две строки, кэшировать результат запроса из БД почти всегда вредно и говорит о проблемах дизайна.Маппинг давно решен в jdbc templates, а типобезопасности ORM не дает, только иллюзию.
Но если нужен кэш - то Spring в помощь или любая другая реализация.
Руслан14.02.2018
08:21:06
08:21:06
> одна простая функция на две строки
можно её привести?
> кэшировать результат запроса из БД
есть несколько кэшей, один из - кешировать объекты которые мы замапили.
Phil14.02.2018
08:21:44
08:21:44
Вообще, я вот ещё не видел разработчиков, которые разбирались бы в БД и использовали ORM. Обычно просто прячут незнание и непонимание под желанием кэширования и т.п.
Руслан14.02.2018
08:22:04
08:22:04
> типобезопасности ORM не дает
схема -> кодогенерация -> модель.
меняю название поля -> ломается билд.
На чистом SQL придется грепать строки. Одно это оправдывает существование ORM
Phil14.02.2018
08:22:46
08:22:46
Ага, а двойную совместимость при смене версий ты как делаешь?
GooglePhil14.02.2018
08:23:03
08:23:03
Нет, грепать ничего не надо )
Руслан14.02.2018
08:23:40
08:23:40
Ага, а двойную совместимость при смене версий ты как делаешь?
у меня будет два поля в переходной модели, потом старое удалю.
Mikhail14.02.2018
08:23:57
08:23:57
Большинству надо, чтобы было просто, поэтому ORM и NoSQL так и популярны.
Phil14.02.2018
08:24:52
08:24:52
Ну, большинство даже не думает, а что такое просто, потому в среднем выигрывают худшие из технологий.
Собственно, NoSQL показательны, да.
> одна простая функция на две строки
можно её привести?
> кэшировать результат запроса из БД
есть несколько кэшей, один из - кешировать объекты которые мы замапили.
Ну, для нормального решения скорее всего return deserialize(data,candidate.class) или что-то в этом роде. Так как плодить кучу мелких колонок в бд обычно вообще не нужно. В крайнем случае конструктор от пяти полей, делов то, один раз маппер написать в Dao.Руслан14.02.2018
08:30:24
08:30:24
json сериализатор/десериализатор тоже самим писать?
Phil14.02.2018
08:30:30
08:30:30
Но вообще проверка SQL - дело ide, она даже справляется в простых случаях. А в сложных уже никто.
А зачем самим? Jackson вполне написан.
Руслан14.02.2018
08:31:15
08:31:15
А зачем мне самому маппер писать с кэшем, если он есть в ORM/jooq?
Phil14.02.2018
08:32:22
08:32:22
Ну, потому что поддержки json там нет, массивов, подозреваю, нет, всех функций нет.
А кода писать приходится очень много, пример сверху показателен. И плохого кода.
И жёсткие ограничения на работу с БД, структуры классов и т.п
И у тебя ещё простой запрос, без пары with, разворачивания массивов и генераторов.
Но вообще в нормальном коде работа с БД занимает так мало места, что обсуждать, в общем, нечего. Пока тормозить не начинает.
Igor14.02.2018
08:43:15
08:43:15
Ну, потому что поддержки json там нет, массивов, подозреваю, нет, всех функций нет.
В JOOQ дописывается все легко. Для Json первым делом написал binding :)Руслан14.02.2018
08:43:29
08:43:29
Ну т.е. из-за того что мне может когда-нибудь понадобится что-то сложное для которого я смогу использовать например https://cayenne.apache.org/docs/4.0/cayenne-guide/#sqltemplate я должен с самого начала пилить велосипеды, писать на чистом SQL без сгенерированной модели и вот это все? Не убедительно.
Если же мне с самого начала будет понятно что нужно использовать фичи базы которой нет в ORM, я возьму JOOQ. Код поддерживать легче чем строки
А кода писать приходится очень много, пример сверху показателен. И плохого кода.
Легко читается, понятен, работает. Ломается при обновлении модели. На SQL было бы хуже, если брать решение в целом, имхо. Но чтобы судить, неплохо бы видеть перед глазами решение на SQL, чтобы оценить предметно плюсы и минусы, а не размахивать руками в воздухе)
Kira14.02.2018
08:46:53
08:46:53
В пользу хибера - кэши там для уменьшения количества запросов к базе, запросы надо экономить
Phil14.02.2018
09:05:45
09:05:45
Ну т.е. из-за того что мне может когда-нибудь понадобится что-то сложное для которого я смогу использовать например https://cayenne.apache.org/docs/4.0/cayenne-guide/#sqltemplate я должен с самого начала пилить велосипеды, писать на чистом SQL без сгенерированной модели и вот это все? Не убедительно.
Если же мне с самого начала будет понятно что нужно использовать фичи базы которой нет в ORM, я возьму JOOQ. Код поддерживать легче чем строки
Ну, как только ты используешь в ORM коде sqltemplate, то о типобезопасности можно забыть, она уже автоматически не проверяется. А ведь всегда приходиться такое писать.GoogleРуслан14.02.2018
09:07:02
09:07:02
Ну, как только ты используешь в ORM коде sqltemplate, то о типобезопасности можно забыть, она уже автоматически не проверяется. А ведь всегда приходиться такое писать.
Почему, у меня всё ещё остаются имена пропертей (смотри код выше). Не все идеально становится (как в пределах орм) но все ещё терпимоPhil14.02.2018
09:08:44
09:08:44
Ну т.е. из-за того что мне может когда-нибудь понадобится что-то сложное для которого я смогу использовать например https://cayenne.apache.org/docs/4.0/cayenne-guide/#sqltemplate я должен с самого начала пилить велосипеды, писать на чистом SQL без сгенерированной модели и вот это все? Не убедительно.
Если же мне с самого начала будет понятно что нужно использовать фичи базы которой нет в ORM, я возьму JOOQ. Код поддерживать легче чем строки
Но вообще так: ради того, что бы, если повезет и в бизнес-план никогда не будет сложных запросов, я мог бы надеяться на контроль кода работы с БД на этапе сборки, мне приходится писать кучу дополнительного кода (описание модели, длинные строки запросов), добавлять кодогенерацию, ограничивать себя в функциональности и усложнять поддержку? Ну-ну.Почему, у меня всё ещё остаются имена пропертей (смотри код выше). Не все идеально становится (как в пределах орм) но все ещё терпимо
В сложном запросе все равно вылезут имена колонок и таблиц. И опанькиВ JOOQ дописывается все легко. Для Json первым делом написал binding :)
Не верю ) там очень богатый язык работы с json и неочевидное маппинг объекта в набор и колонок и json-сущностей, автоматически сложно разрулить, вживую - очевидно.Igor14.02.2018
09:14:55
09:14:55
Не верю ) там очень богатый язык работы с json и неочевидное маппинг объекта в набор и колонок и json-сущностей, автоматически сложно разрулить, вживую - очевидно.
Мне нужен был весьма ограниченный функционал по работе с json (если интересено конкретно – скажите, поищу), так что создал простенькие extension функции для condition-ов. А маппинг в json работает из коробки. (после написания binding-а естественно)Phil14.02.2018
09:32:58
09:32:58
Ну, нам не нужно, у нас чуть другой подход к работе с json, да и JOOQ не нужен, и так работа с бд занимает минимум места и кода (но много внимания, но это уже другой вопрос).
nikita14.02.2018
09:44:44
09:44:44
Ну, большинство даже не думает, а что такое просто, потому в среднем выигрывают худшие из технологий.
пять баллов. много похожих IT-историй в одной фразе.Phil14.02.2018
09:46:04
09:46:04
При всей моей любви к JB, я надеюсь, что Котлин не станет лидирующей технологией.
Ну, пока Котлин хорошо спланированная прагматичная технология, а что бы он победил всех, его придется изрядно испортить, надобавлять возможностей прострелить себе ногу (которых и так уже довольно много), добавить ненужных хайповых фенечек и т.п. В общем, сделать очередным JavaScript со встроенной поддержкой MongoDB.
Sergey14.02.2018
09:51:55
09:51:55
Денис14.02.2018
09:53:41
09:53:41
Ну, пока Котлин хорошо спланированная прагматичная технология, а что бы он победил всех, его придется изрядно испортить, надобавлять возможностей прострелить себе ногу (которых и так уже довольно много), добавить ненужных хайповых фенечек и т.п. В общем, сделать очередным JavaScript со встроенной поддержкой MongoDB.
Я достаточно уважаю людей из JB, чтобы считать, что целью разработки языка является не "самый популярный язык на свете". Они, кажется, разумнее. :)
Andrew14.02.2018
09:54:09
09:54:09
субъективщина, но по мне он уже лучше джавы, тайпскрипта и заходит на обгон го. :)
Phil14.02.2018
09:56:31
09:56:31
Ну, мне вот тоже Котлин нравиться (хотя в первых версиях я на него сильно ругался), так что тоже надеюсь, что он не станет победившей, а будет просто хорошей технологией )
Andrew14.02.2018
09:58:32
09:58:32
На тот же го поводов ругаться сильно больше, и тем не менее на него люди успешно спрыгивают с джав, рубей, пайтонов и т.п. Я к тому, что не обязательно подстилаться под нужды каждого, чтобы быть лидером (обычно, между делом, как раз наоборот).
Phil14.02.2018
10:00:47
10:00:47
У Java все еще есть огромный плюс, про который все забывают - в ней что бы прострелить себе ногу, нужно специально постараться (или добавить какую-нибудь кодогенерацию и аспекты). Это очень существенно на больших проектах и пока языков-конкурентов нет )
Mikhail14.02.2018
10:02:27
10:02:27
я б в котлин добавил тайпклассы и newtype из хаскелл и все, 100% мой язык
Елизаров намекал на то, что newtype добавят скоро
Sergey14.02.2018
10:03:31
10:03:31
Елизаров намекал на то, что newtype добавят скоро
уже есть в дев версии (или в какой то ветке). inline классыMikhail14.02.2018
10:03:38
10:03:38
а тайпклассы пилят ребята из arrow, надесь у них получится продвинуть эту идею
Andrew14.02.2018
10:03:57
10:03:57
И при этом многие используют bytecode weaving и эти самые кодогенераторы на аннотациях. Так что в итоге получается, что шансов в среднестатистическом джава-проекте отстрелить себе ногу больше, чем в котлине, ибо то же самое, но за счёт сторонних решений.
GoogleAndrew14.02.2018
10:04:37
10:04:37
inline class сейчас одну проперти поддерживает, потому это не newtype, это typedef.
Igor14.02.2018
10:04:43
10:04:43
я б в котлин добавил тайпклассы и newtype из хаскелл и все, 100% мой язык
Ну такое, лучше взять haskell и не насиловать kotlin (и ооп-девелоперов, которых большинство, НЕ ооп концептами)
(ну или скалу на крайняк)Mikhail14.02.2018
10:05:23
10:05:23
Ну такое, лучше взять haskell и не насиловать kotlin (и ооп-девелоперов, которых большинство, НЕ ооп концептами)
(ну или скалу на крайняк)
а чем это тайпклассы плохо ложатся на ум ооп?Phil14.02.2018
10:06:11
10:06:11
Угу, потому Котлин и лучше. Пока и в нем не появиться куча микроскопов, используемых как молотки.
Впрочем, надеюсь, что расширениия компилятора будут давать больше.
Кстати, идеальный ORM (вернее, статическую проверку маппинга и SQL-кода) лучше всего делать именно через расширения комплятора. Правда, иногда они будут выдавать всякое некорректное (
Andrew14.02.2018
10:07:30
10:07:30
Ну такое, лучше взять haskell и не насиловать kotlin (и ооп-девелоперов, которых большинство, НЕ ооп концептами)
(ну или скалу на крайняк)
Почему? С теми же каналами и корутинами я в итоге не создавал новые классы, а выбрасывал их, избавляясь от сайдэффектов. Так что на котлине можно писать в разных стилях, но при этом остаётся плюс в достаточно лёгкой возможности соединять разные миры. Ну и не забываем о мультиплатформе.Mikhail14.02.2018
10:07:36
10:07:36
inline class сейчас одну проперти поддерживает, потому это не newtype, это typedef.
не, это как раз таки в этом и суть newtypeAndrew14.02.2018
10:08:20
10:08:20
не, это как раз таки в этом и суть newtype
Окей, спасибо, мне иначе рассказывали, пойду почитаю документацию :)Mikhail14.02.2018
10:08:26
10:08:26
Ну такое, лучше взять haskell и не насиловать kotlin (и ооп-девелоперов, которых большинство, НЕ ооп концептами)
(ну или скалу на крайняк)
тем более, мне, как Android разработчику очень сложно взять haskell)Окей, спасибо, мне иначе рассказывали, пойду почитаю документацию :)
там суть в том, что все тайпчекается, но на этапе компиляции эти типы инлайнятся и заменяются на подстановку своей пропертиIgor14.02.2018
10:09:14
10:09:14
тем более, мне, как Android разработчику очень сложно взять haskell)
А твоим коллегам (которые только java 1.6 и видели в большистве), думаешь легко будет такой код поддерживать?Andrew14.02.2018
10:10:34
10:10:34
там суть в том, что все тайпчекается, но на этапе компиляции эти типы инлайнятся и заменяются на подстановку своей проперти
Да, увидел. Вероятно, мне рассказывали о data, называя это newtype такие же специалисты по хаскеллю, как и я сам :DMikhail14.02.2018
10:10:37
10:10:37
А твоим коллегам (которые только java 1.6 и видели в большистве), думаешь легко будет такой код поддерживать?
да, если им обьяснить некоторые концепции в понятной манере. Например, тайпклассы можно обьяснить как реализацию интерфейса extension-функциями (как то ведь extension функции поняли), или как паттерн адаптер (или какой там больше подходит из GoF)и как то такие вещи, как иммутабельность и чистые функции продвигаются и в java-сообществе, не говоря уже о котлинистах
Igor14.02.2018
10:11:57
10:11:57
да, если им обьяснить некоторые концепции в понятной манере. Например, тайпклассы можно обьяснить как реализацию интерфейса extension-функциями (как то ведь extension функции поняли), или как паттерн адаптер (или какой там больше подходит из GoF)
Ну так берите скалу и в перед, там и HKT есть и теор. можно на android завестиMikhail14.02.2018
10:12:21
10:12:21
Ну так берите скалу и в перед, там и HKT есть и теор. можно на android завести
под скалу никогда не будет нормального туллинга из-за макросовкак говорили ребята из JB
Andrew14.02.2018
10:12:49
10:12:49
А твоим коллегам (которые только java 1.6 и видели в большистве), думаешь легко будет такой код поддерживать?
Динозавры, которые до сих пор даже лямбд из восьмой джавы не щупали, в любом случае будут страдать рано или поздно. Зачем мелочиться-то)Igor14.02.2018
10:13:03
10:13:03
под скалу никогда не будет нормального туллинга из-за макросов
Так не используйте их, вас как будто кто-то заставляет, “коты” и скалази и без них работают (в основном)Phil14.02.2018
10:15:20
10:15:20
О, кстати, о всяком умном и расширении языка.
Мне вот не хватает инструментов управления исключительными ситуациями (или ошибками, не суть важно).
Есть какой-то классический Result<Data,EnumOfErrors>, тут все просто и понятно.
Но если у меня сложная бизнес-логика, то набор возможных ошибок может нарастать на разных инфраструктурных уровнях и хочется расширять этот Enum, но так, что бы в любой момент видеть, а какие конкретно ошибки могут быть без их явного описания и маппинга. И разбирать их через when на верхнем уровне, разумеется )
Checked exceptions этого не дают делать, увы. Расширяемых enum тоже нет. Sealed class тут тоже не помогут (
Есть какие-то умные варианты?
GooglePhil14.02.2018
10:16:36
10:16:36
Хм, попробую )
Mikhail14.02.2018
10:16:53
10:16:53
а хотя искать не надо
Result<Data, List<EnumOfErrors»
или тебе не это надо?
Phil14.02.2018
10:17:28
10:17:28
Нее, не это )
Mikhail14.02.2018
10:18:18
10:18:18
ааа, тебе надо, чтобы было несколько разных enum на разных слоях и ты мог их все композировать?
Phil14.02.2018
10:18:23
10:18:23
Ага!
Скорее даже именно что расширять каждый и по call stack видеть, какие расширения могут быть (или вручную это показывать)
Ну, и что бы Idea все это красиво рисовала )
Mikhail14.02.2018
10:19:47
10:19:47
sealed class иерархию не рассматривал?
Igor14.02.2018
10:19:54
10:19:54
если найду и скину на F#, разберешь?
Вот, когда мне не хватает котлина, я беру F# пишу под android поверх RN и чувствую себя отлично.Даниил14.02.2018
10:21:02
10:21:02
вот завезли бы в F# тайпклассы и HKP :c
Igor14.02.2018
10:22:11
10:22:11
На фиг не надо. Хотя простые тайп-классы планируют когда-нибудь завести в C#, а там какой-нибудь интероп придумают.
Mikhail14.02.2018
10:23:15
10:23:15
Ага!
типа
sealed class CustomException
sealed class DataException : CustomException()
sealed class ApiException: DataException()
data class ConversionException: DataException()
sealed class DomainException: CustomException()Phil14.02.2018
10:23:29
10:23:29
У sealed тут нет разницы от общего enum, насколько я понимаю. Расширять "позже" все равно нельзя.
Технически такое, наверно, можно сделать через кучу интерфейсов, но очень неудобно.
Mikhail14.02.2018
10:24:37
10:24:37
нууу, а зачем расширять класс ошибок?
Anton14.02.2018
10:24:59
10:24:59
Открыть в Telegram