Ответы пользователя по тегу Go
  • Доступ к методам и функция уровнем выше?

    @comdivuz
    Ну обычно требуется явное знакомство.
    А все явное лучше неявного

    type Parent struct {
        GroupId int
        children []*Children
    }
    type Child struct {
        parent *Parent
    }
    func (p *Parent) Add(c *Child) {
        p.children = append(p.children, c)
        c.parent = p
    }
    func (p *Parent) Children() []*Child { return p.children }
    func (c *Child) GroupId() {return c.parent.GroupId }


    Как-то так

    ```
    Допустим это не сработает при демаршализации
    типа вы хотите все сразу из JSON вычитывать, ну тогда тоже можно явно сделать промежуточный объект

    type parentJson struct {
        GroupId int `json:"group_id"`
        Children []*Child `json:"children"`
    }
    func (pj *parentJson) apply(p *Parent) {
        p.GroupId = pj.GroupId
        for _, c := range pj.Children {
              p.Add(c)
        }
    }
    type Parent struct {
        GroupId int 
        сhildren []*Children
    }
    type Child struct {
        parent *Parent
    }
    func (p *Parent) UnmarshalJSON(data []byte) error {
         var pj parentJson
         if err := json.Unmarshal(data, &pj); err != nil {return err}
         pj.apply(p)
    }
    func (p *Parent) Add(c *Child) {
        p.children = append(p.children, c)
        c.parent = p
    }
    func (p *Parent) Children() []*Child { return p.children }
    func (c *Child) GroupId() {return c.parent.GroupId }
    Ответ написан
    Комментировать
  • Почему некоторые программисты на GO работают с бд на голом SQL без ORM?

    @comdivuz
    Основной стек был Java/Kotlin, сейчас Go - база основная Postgres. Продукты сервисные и внутренние, задачи адаптации и совместимости сразу под многие движки нет.

    Ни там ни там не использовали ORM (точнее во времена Spring использовали и гибернейт и JPA и еще что-то, но от всего отказались). Иногда пилим "свой ORM", обычно это кодогенерация (из Yaml и в SQL и в GO) и обслуживает конкретный проект - это делается если система действительно сильно классическая базо-ориентированная и там сплошной CRUD.

    Поясняю почему не ORM, точнее поясню почему никакие "фишки" ORM-движов нам не только не нужны, но и вредны некоторые.

    1. Переносимость между БД - этой задачи не стоит, у нас не внешние продукты для самостоятельной установки куда угодно, у нас четкий стек баз и есть компетенции их использовать более продвинуто и с использованием всех возможностей, больше чем предлагает ORM
    2. Автоматические миграции из кода - это вообще зло - ни один движок не порождает действительно хороших внятных схем, с доменами, дефолтами GENERATE AS, partition by и прочее, никто также не терпит автомиграций только от наката какого-то микросервиса в стек, миграциями управляем очень осторожно как отдельным процессом, тем более в микросервисной архитектуре обычно нет никакого "владельца" одного базы из сервисов
    3. Мапинг кортежей в структуры - это на самом деле совершенно не сложно и свои, причем более удобные по поведению прокладыки пишутся за час и складываются в общую библиотеку и там можно лучше зарешать какие-то преобразования в DTO
    4. Что касается самих запросов - мы обычно оптимизируем базы вьюхами, функциями и т.п. и соответственно одни и те же структуры порой запитываются из разных источников, то же самое касается кэширования, связывания сущностей и т.п. - базовые вещи легко кодогенерятся и не требуют никакой прослойки библиотечно, сложные все равно писать ручками в хитрые запросы
    5. Всякие там каскадные обновления и множественные вставки - по факту это только от лени и в учебных проектах - это все так здорово. на деле лучше немного помучиться и сделать более внятные и явные бизнесовые операции по обновлению данных

    Итого - ORM бы дал нам выигрыш если бы требовалась переносимость, если бы проекты были бы совсем рутинные и если бы не было компетенций по работе с БД. Для сложных внутренних проектов с наличием квалифицированных разработчиков БД - ORM как пятая нога собаке.

    Еще раз подчеркну - в контексте - ORM - как "некая либа которая делает ORM и такая няшная, все умеет", если мы говорим про ORM как тип операции (Object Relation Mapping) то естественно такие операции есть и вспомогательные функции для этого тоже.
    Ответ написан
    Комментировать