GC
ага
Size: a a a
2020 June 30
GC
не может
GC
вру
GC
GC
то есть с тоже прочекать стоит
У
всем привет, кто сталкивался с ошибкой, когда при вендоринге приватного модуля из гитлаба
просто видел человека у кого такая трабла случалась
https://gitlab.com/gitlab-org/gitlab/-/issues/30612
go get gitlab.com/<company>/<subgroup>/<repo>/<subdirectory>отдает ошибку
fatal: repository 'https://gitlab.company.ru/group/repo.git/' not foundтоесть go get срезает еще одну сабгруппу
просто видел человека у кого такая трабла случалась
https://gitlab.com/gitlab-org/gitlab/-/issues/30612
Н
Вопрос архитектурный: у нас есть кэш и основная БД. Сначала надо пойти в кэш, проверить есть ли там данные, если нет, то пойти в БД, и в итоге взять, оттуда где лежит. В плане организации логики кэш у нас является отдельной инфраструктурной деталью, либо же часть БД? То есть обращение к кэшу у нас должно быть скрыто за гейтвеем базы? Или же отдельно свой гейтвей?
Например:
И логика обращения к кэшу скрыта в методе
Явно показываем в юзкейсе, что обращаемся к кэшу
Например:
post, err := controller.db.GetPostById(params.PostId)
if err != nil {
return result, errors.InternalError
}
И логика обращения к кэшу скрыта в методе
GetPostById, либо же
post, err := controller.cache.GetPostById(params.PostId)
if err != nil || !post.Exists() {
post, err = controller.db.GetPostById(params.PostId)
if err != nil {
return result, errors.InternalError
}
}
Явно показываем в юзкейсе, что обращаемся к кэшу
DP
Улица
всем привет, кто сталкивался с ошибкой, когда при вендоринге приватного модуля из гитлаба
просто видел человека у кого такая трабла случалась
https://gitlab.com/gitlab-org/gitlab/-/issues/30612
go get gitlab.com/<company>/<subgroup>/<repo>/<subdirectory>отдает ошибку
fatal: repository 'https://gitlab.company.ru/group/repo.git/' not foundтоесть go get срезает еще одну сабгруппу
просто видел человека у кого такая трабла случалась
https://gitlab.com/gitlab-org/gitlab/-/issues/30612
Это известная гитлабная херня, она не лечится
У
Это известная гитлабная херня, она не лечится
((, но за инфу спасибо
АС
Вопрос архитектурный: у нас есть кэш и основная БД. Сначала надо пойти в кэш, проверить есть ли там данные, если нет, то пойти в БД, и в итоге взять, оттуда где лежит. В плане организации логики кэш у нас является отдельной инфраструктурной деталью, либо же часть БД? То есть обращение к кэшу у нас должно быть скрыто за гейтвеем базы? Или же отдельно свой гейтвей?
Например:
И логика обращения к кэшу скрыта в методе
Явно показываем в юзкейсе, что обращаемся к кэшу
Например:
post, err := controller.db.GetPostById(params.PostId)
if err != nil {
return result, errors.InternalError
}
И логика обращения к кэшу скрыта в методе
GetPostById, либо же
post, err := controller.cache.GetPostById(params.PostId)
if err != nil || !post.Exists() {
post, err = controller.db.GetPostById(params.PostId)
if err != nil {
return result, errors.InternalError
}
}
Явно показываем в юзкейсе, что обращаемся к кэшу
Реализации кеша и бд могут имплиментировать один интерфейс. Этим интерфейсом и пользуйся в сервисах.
Н
Реализации кеша и бд могут имплиментировать один интерфейс. Этим интерфейсом и пользуйся в сервисах.
у нас не выбор кэш или БД. У нас надо обратиться и к кэшу и к БД
S
Вопрос архитектурный: у нас есть кэш и основная БД. Сначала надо пойти в кэш, проверить есть ли там данные, если нет, то пойти в БД, и в итоге взять, оттуда где лежит. В плане организации логики кэш у нас является отдельной инфраструктурной деталью, либо же часть БД? То есть обращение к кэшу у нас должно быть скрыто за гейтвеем базы? Или же отдельно свой гейтвей?
Например:
И логика обращения к кэшу скрыта в методе
Явно показываем в юзкейсе, что обращаемся к кэшу
Например:
post, err := controller.db.GetPostById(params.PostId)
if err != nil {
return result, errors.InternalError
}
И логика обращения к кэшу скрыта в методе
GetPostById, либо же
post, err := controller.cache.GetPostById(params.PostId)
if err != nil || !post.Exists() {
post, err = controller.db.GetPostById(params.PostId)
if err != nil {
return result, errors.InternalError
}
}
Явно показываем в юзкейсе, что обращаемся к кэшу
Я обычно в репозитории делаю. И тебе советую вынести работу с базой в слой репозитория и там всё разруливать
DP
Улица
((, но за инфу спасибо
вернее, лечится, но отказом от групп репозиториев (забыл, как оно в терминологии гитлаба)
АС
у нас не выбор кэш или БД. У нас надо обратиться и к кэшу и к БД
реализация кеша может «проглатывать» в себя реализацию базы. и уже в реализации кеша резолви все это.