@scala_ru

Страница 487 из 1499
Andrey
09.02.2017
07:14:15
Нифга подобного. Там есть нормальные миграции на уровне БД.

Не надо каждый объект считывать, потом записывать.

Oleg
09.02.2017
07:14:43
миграция не сможет определить "чем должно было быть заполнено поле, на момент, когда запись создавалась"

ты заполнишь его каким-то дефолтом или NULLом

Google
Andrey
09.02.2017
07:15:04
Так оно и не надо же, ты определяешь это в момент миграции.

Oleg
09.02.2017
07:15:09
при миграции, и оставишь аналогичный IF в коде

Andrey
09.02.2017
07:16:09
Только вот почему то в приложениях на постгресе я не видел этих ифов)) А в трех приложениях на монге, что я видел, они есть...

Oleg
09.02.2017
07:16:18
ну вот в связи с очередным законом Яровой появилась графа "вероисповедание" в форме и ты её кладёшь в данные

как ты её вычислишь при миграции?

нейронной сетью?

Andrey
09.02.2017
07:16:37
Oleg
09.02.2017
07:16:47
А зачем?
чтобы if а не было

и поле было заполнено не пустотой

схема\её отсутствие не решает проблем с миграцией

Oleg
09.02.2017
07:18:04
просто schemaless ДБ дают большую гибкость при обработке полиморфных данных

а schemaful - как правило, более эффективное хранение

Google
Oleg
09.02.2017
07:18:23
и обмен

Andrey
09.02.2017
07:18:24
Схема вообще к миграциям имеет весь отдаленное отношение, при чем тут оно?

Vasily
09.02.2017
07:18:36
Эта проблема решается миграцией,в частности, данные для нового поля могут быть взяты из внешнего источника данных

Oleg
09.02.2017
07:18:40
Andrey
09.02.2017
07:19:01
ты рассказываешь, что if ы в коде уйдут куда-то
Из-за миграций? О_о Ты что-то попутал) Удобные, быстрые миграции это просто один из примеров удобств, которые теряешь при переходе на монгу

Vasily
09.02.2017
07:19:23
Ифы в коде не от базы зависят

Vasily
09.02.2017
07:19:55
А от количества тараканов в голове

И опыта

Andrey
09.02.2017
07:23:04
это твои слова, расскажи, куда if ы уходят при использовании schemaful vs schemaless
Это ты что-то попутал) Я ни слова не говрил ни про schemaful ни про schemaless. Потому что schemaless вариантов не один. Реализаций много разных. Я говорил про конкретные примеры приложений на постгрессе и монге. Того что я видел. Все приложения, что я видел на монге, покрывались каким-то диким количеством говнокода, обслуживающего это самое "schemaless" в монге. И народ просто махал рукой, разбираться в этом болоте, и просто ставил еще один IF

Dmitry
09.02.2017
07:24:36
эм? что там за обслуживание схемалеса в монге?

Aleksei
09.02.2017
07:24:46
я смотрел говно и видел говно, вот примерно что ты сейчас про монгу написал.

Oleg
09.02.2017
07:25:28
Правда в том, что "в монге нет схемы" это полная брехня. Она просто переехала из бд (со всем известного языка и правил), в код приложения. Видел несколько приложений на монге. В каждом из них адок. Простой пример из того что видел. В какой то момент к объекту добавляется поле. И в коде появляется условие if(поле у объеката есть) { делам с ним что то. } А иначе приложение просто падает. Потому что на момент когда объект сохраняли, такого поля у него еще не было.

Nick
09.02.2017
07:26:13
Oleg дык версионность нужна)

Dmitry
09.02.2017
07:26:23
единственное что меня сильно бесит в монге - нет возможности атомарно изменить несколько документов.

(ну и многое бесит по мелочи, но можно терпеть)

Andrey
09.02.2017
07:26:58
я смотрел говно и видел говно, вот примерно что ты сейчас про монгу написал.
Да, именно это я и написал. Не видел ни одного хорошего примера использования монги. И даже теоретически никто не смог объяснить реальных преимуществ, кроме весьма сомнительного переезда схемы из БД в Код.

Dmitry
09.02.2017
07:28:11
теоретически (да и практически) для прототипирования очень хорошо

Google
Andrey
09.02.2017
07:28:15
Все преимущества что я видел, можно описать как "теперь легко можно херак-херак и продакшен". И скромно умалчивается как это все потом поддерживать.

Nick
09.02.2017
07:28:54
@solverit хороший пример эт когда у тебя сторонний api часто меняется

Oleg
09.02.2017
07:28:59
Да, именно это я и написал. Не видел ни одного хорошего примера использования монги. И даже теоретически никто не смог объяснить реальных преимуществ, кроме весьма сомнительного переезда схемы из БД в Код.
теоретически могу объяснить за все решения. Если твои данные имеют формат документа, то OAV будет гораздо более отвратительным решением, чем монга. Если они могут иметь сложную структуру с большим количеством уровней вложенности, то ты будешь многократно проигрывать от 20-слойных джойнов

Oleg
09.02.2017
07:30:51
Оставется вопрос, как поддерживать целостность данных. И что важнее, потеря целостности или скорость.
Вопрос не в скорости. Если все твои операции работают на уровне одного объекта - целостность никуда не денется

Просто не нужно спорить, чей золотой молоток универсальнее

Больше СУБД богу СУБД

Andrey
09.02.2017
07:31:25
Вопрос не в скорости. Если все твои операции работают на уровне одного объекта - целостность никуда не денется
Это очень вырожденный слкчай, когда тв моджешь разбить приложение на несвязанные объекты.

Oleg
09.02.2017
07:31:48
Это очень вырожденный слкчай, когда тв моджешь разбить приложение на несвязанные объекты.
Это абсолютно типичный случай во всех бизнес-логиках, где используется слово "документ"

Andrey
09.02.2017
07:32:12
Просто не нужно спорить, чей золотой молоток универсальнее
Никогда этим не занимался. Но прежде чем обращать других в свою веру, проповеднику неплохо было бы объяснить зачем эта вера нужна))

Как я уже говорил, я вот не вижу ни одного реально примера, где не "отт тут монга тоже будет работать", а "Без монги ты тут соснешь по полной".

Oleg
09.02.2017
07:33:19
Никогда этим не занимался. Но прежде чем обращать других в свою веру, проповеднику неплохо было бы объяснить зачем эта вера нужна))
Концептуальная ошибка. Здесь вообще ни один человек никого не вербовал. Практически все диалоги - это замечания и замечания на замечания

Andrey
09.02.2017
07:33:55
ну значит, мало видел
Вот так и говорят все люди, которые пытались "продать мне монгу". А реальных примеров как не было, так и нет ((

Oleksandr
09.02.2017
07:34:59
@solverit хороший пример эт когда у тебя сторонний api часто меняется
во, единственный настоящий кейс, что я смог придумать за монгу для остального есть способы попроще и бд понадежнее

Daniel
09.02.2017
07:35:20
Orient!
Ну да, любители закрывать баги без фикса.

Aleksei
09.02.2017
07:35:54
а там же еще есть GridFS

Oleg
09.02.2017
07:36:32
Не, я не про тебя лично. Я про тех, кто несет знамя веры в монгу) И сеет смуту среди народа
Ну они говорят, что монга удобна для старта разработки. Очень продуктивна на ранних стадиях. И это правда. Просто нужно напомнить, что есть решения с аналогичным уровнем продуктивности, но которые не превращаются в головные боли "поиска гигабайт потерянных инсёртов" и попыткой остановить цепные падения replication-групп Моё говновыделение вызвал комментарий о том, что дескать монга сама по себе магическим образом приводит к какому-то отвратительному коду

Nick
09.02.2017
07:37:52
продуктивность чем определяется?

Google
Nick
09.02.2017
07:38:07
можно и на постгрях быстро стартануть

Oleg
09.02.2017
07:38:10
продуктивность чем определяется?
Количеством фич в спринт

Nick
09.02.2017
07:39:08
Количеством фич в спринт
странный показатель

Andrey
09.02.2017
07:39:37
Количеством фич в спринт
За много лет, БД вообще ни разу не была тормозом в продуктивности по реализации фич...

Oleg
09.02.2017
07:39:43
можно и на постгрях быстро стартануть
Если иметь прокачанный навык дата-дизайна, можно. С монгой можно без него, поэтому, видимо это и приводит к проблемам позже

странный показатель
Первое, что пришло в голову. Есть лучше?

Admin
ERROR: S client not available

Ivan
09.02.2017
07:41:03
я сталкивался с медленным жестким диском например

из за которого страдает БД в первую очередь

Mikhail
09.02.2017
07:50:01
кто-нибудь гонял flyelephant.net ?

Nikita
09.02.2017
08:17:37
https://speakerdeck.com/jboner/from-microliths-to-microsystems

Nikolay
09.02.2017
08:19:44
Это microservices bla bla?

Oleg
09.02.2017
08:20:35
by Jonas Bonér

Nikita
09.02.2017
08:23:38
не, это свежатина

как раз про монолиты и микросервисы

Oleg
09.02.2017
08:27:13


/gopher

Dim
09.02.2017
08:28:23
человеки, вопрос по интерполяции строк.

Google
Dim
09.02.2017
08:28:42
можно ли использовать ее как простой шаблонизатор в Scala?

например у меня есть строка "Курс $currency $date"

Dim
09.02.2017
08:29:22
не хочеться тянуть шаблонизатор))

и задачка маленькая

Oleg
09.02.2017
08:30:09
и ты просишь индульгенции?

Dim
09.02.2017
08:30:09
есть набор шаблонов, надо туда подставлять значения...разные.

Daniel
09.02.2017
08:30:12
если это не доставляет боли и это работает, то используй это ж всё твое

Oleg
09.02.2017
08:30:31
Нет! Б-г не простит тебя! Use the right tool

Dim
09.02.2017
08:30:43
не не погодите, я не об этом))))

могу ли я как-то сохранить "Курс $currency $date" в списке например, а потом применить параметры?

Oleg
09.02.2017
08:31:17
Шаблоны compile time превращаются в StringContext

Поэтому тебе придётся подключать scala scripting engine , если захочешь прямо вот так использовать

Dim
09.02.2017
08:31:59
о нет

ну вот...

(

тогда уж лучше шаблонизатор прикручу.

Oleg
09.02.2017
08:32:44
good boy

Nikolay
09.02.2017
08:35:08
Oleksandr
09.02.2017
08:41:01
например у меня есть строка "Курс $currency $date"
оно будет каждый раз создавать всю строку, а не инсертить переменные в шаблон ну и нет (из коробки) разных локализаций или там конвертаций валют

если это некритично, тогда можно

Страница 487 из 1499