C
К сожалению, автомиграцию сразу после первого релиза придется убирать. Она довольно тупая и не всегда может сообразить, что надо. Хотя для poc и норм
++
Size: a a a
2020 July 27
AR
т.е. хотя бы попробовать его я бы рекомендовал, прикольная штука
C
но вообще нам пока ent нравится, но мокать его не очень удобно + пока сыровато
хотя issue фиксят быстро
статическая типизация и автокомплит - очень удобно юзать
хотя issue фиксят быстро
статическая типизация и автокомплит - очень удобно юзать
мне не понравилось что нет стриминг чтения и батчей
ЛА
но вообще нам пока ent нравится, но мокать его не очень удобно + пока сыровато
хотя issue фиксят быстро
статическая типизация и автокомплит - очень удобно юзать
хотя issue фиксят быстро
статическая типизация и автокомплит - очень удобно юзать
Горм делает слишком много, ент слишком мало.
Но го вей похоже второе
Но го вей похоже второе
AR
мне не понравилось что нет стриминг чтения и батчей
да, там есть открытые issue для этого, вроде даже в роадмапе
VM
Я бы на месте работодателя не платил за изучение и работу с горм, уж очень контрпродуктивно и отклонение от прямых обязанностей - разработке на го
C
да, там есть открытые issue для этого, вроде даже в роадмапе
угу
VM
но вообще нам пока ent нравится, но мокать его не очень удобно + пока сыровато
хотя issue фиксят быстро
статическая типизация и автокомплит - очень удобно юзать
хотя issue фиксят быстро
статическая типизация и автокомплит - очень удобно юзать
А в чем неудобство моков? Или, точнее, особенность моков энта от не энта?
AR
А в чем неудобство моков? Или, точнее, особенность моков энта от не энта?
там такая архитектура, что сложно выделить подмножество интерфейса и через dependency inversion заюзать, придется использовать god-структуру от ent, из которой есть доступ ко всем сущностям
AR
т.е. там инстанцируешь ent.Client, а у него в полях есть все сущности, типа вот такого псевдокода:
c := NewClient()получается, что слой repository нужно будет в любом случае выделять в архитектуре, и уже из него обращаться к ent.
u := с.Users.GetByID("foo")
v := c.Videos.Query(videos.ByUser(u))
v.Update().SetDescription("foo")
AR
но можно конечно забить на всё и прям из chi хендлера юзать ent, но тогда это сложно будет тестировать иначе как интеграционно
C
но можно конечно забить на всё и прям из chi хендлера юзать ent, но тогда это сложно будет тестировать иначе как интеграционно
для небольших апп это топ тема
МП
но вообще нам пока ent нравится, но мокать его не очень удобно + пока сыровато
хотя issue фиксят быстро
статическая типизация и автокомплит - очень удобно юзать
хотя issue фиксят быстро
статическая типизация и автокомплит - очень удобно юзать
Но ведь в ней нет db first. Т е нужно самому схему прописывать. Это не dry и оч ипёт делать самому руками
AR
Мимо Проходящий
Но ведь в ней нет db first. Т е нужно самому схему прописывать. Это не dry и оч ипёт делать самому руками
она schema first
AR
мы генерируем миграции через ent + migrate, складываем их в папочку
_migrations, получается _migrations/001_something_new.up.sql, потом эмбедится в бинарьC
мы генерируем миграции через ent + migrate, складываем их в папочку
_migrations, получается _migrations/001_something_new.up.sql, потом эмбедится в бинарьent сам может в миграции, зачем тулы слева?
AR
ent сам может в миграции, зачем тулы слева?
может, да
нам нужен ручной контроль над тем, что выполняется в бд
нам нужен ручной контроль над тем, что выполняется в бд
AR
т.е. просто "offline mode" юзаем, как-то спокойнее с ним
МП
Вообще дело хорошее, тоже хочу попробовать на новых бд
МП
т.е. там инстанцируешь ent.Client, а у него в полях есть все сущности, типа вот такого псевдокода:
c := NewClient()получается, что слой repository нужно будет в любом случае выделять в архитектуре, и уже из него обращаться к ent.
u := с.Users.GetByID("foo")
v := c.Videos.Query(videos.ByUser(u))
v.Update().SetDescription("foo")
Вот здесь же у вас 3 запроса. Не смущает, что можно в один?