Nikita
Ну там миграции по идее на уровне Rails решаются?
yopp
Вопрос с миграциями в документном хранилище легко вообще не решается.
yopp
Это набор специфичных для каждого приложения компромиссов
Nikita
Ну хотя бы вручную циклами мигрировать базу.
Egor
Alexander
Есть YADM на питоне. Нас устраивает.
Alexander
Но миграций нет. У нас под них отдельный механизм, с монгой мало связанный.
Nikita
Т.е. миграций нет нигде?
Nikita
Так а что с Mongoose не так? Ruby пока не готов учить.
Nikita
Есть другие нормальные ODM, кроме Mongoid?
Dmitriy
Пока так и не понял вашу проблему, но для миграций mongodb есть вот такой пакет например https://github.com/golang-migrate/migrate устанавливается как внешняя тулза, которая выполняет миграции. Единственное что для компиляции потребуется golang на машине. Под капотом использует mongodb command в качестве языка описания файлов миграций
Dmitriy
Но если вам нужно в составе какой-то odm, то наверное доктрины я в своей практики приличного не встречал
Nikita
Dmitriy
А ODM есть для Golang?
Есть, официальная от mongodb https://github.com/mongodb/mongo-go-driver
yopp
Тред про миграции в монге
Dmitriy
Есть, официальная от mongodb https://github.com/mongodb/mongo-go-driver
Этот драйвер к слову используется в пакете миграций что я выше скидывал
Dmitriy
Есть, официальная от mongodb https://github.com/mongodb/mongo-go-driver
Хотя наверное это не совсем про odm - это все таки драйвер. odm видел для go от first.db (если не путаю), но по факту она очень куцая и не предоставляет множество функционала. Поэтому удобнее использовать напрямую драйвер и запросы
yopp
Nikita
Ну я понял, только добавлять новое, старое не трогать
Nikita
Т.к. с откатами будут проблемы
yopp
Да. Но это и есть миграция с определёнными условиями
yopp
«оптимальность» это задача оптимизации, она стоит самой самой самой последней. Более того, оптимизация схемы это один из последних способов оптимизации, когда более простые не работают.
yopp
И ничего не мешает по изменить структуру оставив старые поля
yopp
Потому что размер документа это тоже одна из последних вещей в списке на оптимизацию
Nikita
Спасибо за советы. Но всё равно, даже для ограниченных миграций - мало инструментов :-(.
yopp
Потому что нет схемы
yopp
А миграция это про схему
yopp
Вы тред не очень внимательно почитали
Nikita
Т.е. прямо внутри кода "миграции"?
yopp
Значит что нет универсального способа «миграции», потому что это часть бизнес логики.
yopp
Этот набор компромиссов которые вы выбираете исходя из вашей конкретной бизнес-задачи.
Не пытайтесь к документным хранилищам применять логику табличных хранилищ, она тут практически полностью не применима
Nikita
Просто хотелось бы, чтобы версионность была, но может я просто ещё не до конца понял всю суть документных хранилищ. Видел в документации к Doctrine, что например при переименовании полей, указывается список возможных имён поля в модели, и при перезаписи, уже запишется наиболее актуальный вариант.
yopp
Просто хотелось бы, чтобы версионность была, но может я просто ещё не до конца понял всю суть документных хранилищ. Видел в документации к Doctrine, что например при переименовании полей, указывается список возможных имён поля в модели, и при перезаписи, уже запишется наиболее актуальный вариант.
Вы не с того конца начали. Вам не версионирование нужно, вам нужно решать конкретные проблемы.
yopp
Они у вас есть?
yopp
Если у вас их нет, вам не нужно их решать
Nikita
Проблем нет. Пытаюсь понять, насколько применима MongoDB для JSON API.
yopp
Что такое JSON API
Nikita
Restful
yopp
Вы в где-то в космосе упоролись абстракциями
yopp
Вернитесь к конкретной бизнес-задаче
Nikita
Ну ок, перечислите, в каких кейсах вы используете MongoDB, в каких реляционные БД?
yopp
Монга с натяжкой уже реляционное хранилище, только нет явных гарантий целостности через механизм похожий на FK
Nikita
По мне так Restful вполне понятно. Есть коллекции в БД. Причём в MongoDB они уже сразу в JSON, в отличии от классических реляционных БД.
yopp
в монге не json
yopp
По мне так Restful вполне понятно. Есть коллекции в БД. Причём в MongoDB они уже сразу в JSON, в отличии от классических реляционных БД.
У вас какие данные будут храниться? Совершенно не важно как вы к ним будете ходить, по gRPC, SOAP, AMQP или через UPD тоннель
Nikita
Коллекции в основном. Ну т.е. сложной логики, требующих сложных SQL запросов не ожидается.
yopp
Коллекции чего?
yopp
Для того чтоб понять какое хранилище вам лучше подходит, вам нужно оперировать не интерфейсами, а структурами данных и требованиям к выборкам этих структур
yopp
Вы исходите что есть какая-то общая классика. Для меня классика это сотни гигабайт небольших событий из какойнибцдь рекламной банерокрутилки
yopp
У вас есть конкретное приложение под которое вы выбираете хранилище?
Nikita
Да, есть кейс. Простое приложение. Хотел попробовать, насколько применима MongoDB. Но миграции там понадобятся скорее всего.
yopp
Вот сформулируйте структуры данных, составьте планы запросов и после этого подбирайте себе хранилище
yopp
В настоящий момент у вас проблема слишком абстрактно сформулирована, чтоб на неё возможно было дать какой-то ответ
Aleksandr
относительно небольшие объемы данных изи мигрировать через aggregate+out/merge
yopp
относительно небольшие объемы данных изи мигрировать через aggregate+out/merge
Через $out только в новую коллекцию.
yopp
$merge завезли две недели назад
Aleksandr
ну да, но можно же
Aleksandr
мигрировать лучше в новую бд ваще имхо, чтобы старую не портить
Aleksandr
в отсутсивие пллной постановки задачи можно только сказать что монго отличный инструмент и множество задач им решается успешно
yopp
Да нет никакой проблемы с инструментами, если проблема понятна
yopp
Абстрактные «миграции» это не проблема в монге, потому что нет схемы. Все документы в коллекции могут иметь свою собственную структуру
Aleksandr
ага
Nikita
в отсутсивие пллной постановки задачи можно только сказать что монго отличный инструмент и множество задач им решается успешно
Понял. По стеку всё таки сомневаюсь насчёт Ruby. Думаю выбрать Node.js или Golang.
Aleksandr
на ноде изи вход
Aleksandr
надо входить через то что знаешь уже
Nikita
Ну вот с Ruby я вообще никак.
Aleksandr
ну и не надо думать про него тогда
yopp
Я вам настоятельно рекомендую сначала разобрать с тем что вы хотите получить в итоге
yopp
Потому что вы сейчас выбираете инструменты не имея достаточного понимания коечного результата
yopp
Как следствие вы сейчас не имеете достаточного количества информации для сравнения технологий.
Реальность такова что надо делать на том, на чём из говна и палок можно собрать прототип на коленке за ночь
Aleksandr
как я понял человек вобщем-то опыт хочет получить