По поводу трассировки запросов, она есть, но в статье не описана. Так же у нас есть агрегирующий сбор статистики по SQL запросам: время выполнения(мин, макс, среднее), количество запросов за период, выбираемое количество строк и многое другое. Ещё доступна информация, сколько занимал каждый отдельный запрос в рамках выбранного одного апи вызова ( по trace_id). Собственно через эти инструменты и собирается текущая картина по сло и бюджету на ошибки.
По поводу инструментов профилирования операторов не в курсе (и есть ли они в Pg), как правило мне пока хватает визуализации от tensorflow, есть в списке ссылок
Кажется, в такой ситуации может помочь вот такой метод m.File().PkgPath.Matches(), где m - это dsl.Matcher, насколько понял он появился через ~2 месяца после твоего issue и по моим небольшим локальным тестам метод должен помочь, если не сложно можешь проверить на своих данных и дать фидбек здесь или в https://t.me/go_critic_ru?
Есть вопрос по поводу пункту 14, а именно Fatal ошибки. Под fatal подразумевается deadlock, out of memory , out of index и тд или просто серьезные ошибки, после которых надо закончить функцию/горутину?
Так как если это именно fatal ошибка (например deadlock), то как вообще можно делать какой-то дополнительный детализированный вывод помимо стандартного?
Как пример: удобен при реализации обращений к бд на большие объемы данных, где используется SQL вида:
c yield:
function getDbValues() {
$query = "
SELECT *
FROM table
WHERE :id > id
LIMIT 1000
ORDER BY id DESC
";
$id = 0;
for {
$rows = executeQuery($query, $id);
yield $rows;
if (count($rows) === 0) {
return ;
}
$id = $rows[count($rows)];
}
}
без yield:
function getDbValues($lastID) {
$query = "
SELECT *
FROM table
WHERE :id > id
LIMIT 1000
ORDER BY id DESC
";
return executeQuery($query, $lastID);
}
В случае без yield логику выбора последнего id необходимо будет вынести в место вызова функции из-за чего код может выглядеть менее красивым/читабельным :)
Так же можно дополнительно сэкономить время, если выполнять запрос через PreparedStatement в функции генераторе. Это можно, конечно же, реализовать и через return, но опять же через yield это будет сделать проще/читабельней.
Конечно, бывают случаи, когда кого-то осеняет уже во время ревью — тогда это предложение, если оно действительно ценное, стоит задокументировать в issue-трекере и никогда к нему больше не возвращаться
Почему стоит задокументировать и не возвращаться? Можно поподробнее раскрыть предложение, что имелось в виду.
Я не опровергаю, что создание ПО одиночками невозможно, но все же в компаниях как правило для создания продукта задействуют команду из нескольких людей, необязательно только разработчиков, и статья как раз о том какие принципы должны быть заложены в такой команде и чего стоит избегать.
Рад что вам понравилось )
По поводу трассировки запросов, она есть, но в статье не описана. Так же у нас есть агрегирующий сбор статистики по SQL запросам: время выполнения(мин, макс, среднее), количество запросов за период, выбираемое количество строк и многое другое. Ещё доступна информация, сколько занимал каждый отдельный запрос в рамках выбранного одного апи вызова ( по trace_id). Собственно через эти инструменты и собирается текущая картина по сло и бюджету на ошибки.
По поводу инструментов профилирования операторов не в курсе (и есть ли они в Pg), как правило мне пока хватает визуализации от tensorflow, есть в списке ссылок
Добрый вечер, по поводу графического представления хорошее предложение, на самом деле, просто не пришло в голову, постараюсь добавить на неделе.
По поводу первого вопроса про ограничение, это скорей особенность бизнес процесса.
Про 500 ISBN, это пример выборки поисковой выдачи для проверки актуальных цен. В запросе может быть разный размер выборки, как и ее содержание.
Когда будет статья про рендеринг караванов?
Уже четвертый месяц жду...
Кажется, в такой ситуации может помочь вот такой метод
m.File().PkgPath.Matches()
, где m - это dsl.Matcher, насколько понял он появился через ~2 месяца после твоего issue и по моим небольшим локальным тестам метод должен помочь, если не сложно можешь проверить на своих данных и дать фидбек здесь или в https://t.me/go_critic_ru?Пример использования можно посмотреть тут:
https://github.com/quasilyte/go-ruleguard/blob/003e476add1338428d96be12d3cc24b99c955b60/analyzer/testdata/src/filtertest/rules.go#L168
Единственное, метод не будет работать, если решишь его протестировать, как описано в 4 приеме, через golang.org/x/tools/go/analysis/analysistest, так как библиотека до сих пор не имеет поддержки модулей. Если не ошибаюсь проблема описана тут: https://github.com/golang/go/issues/37054.
Привет, спасибо за фидбек, а не подскажешь о каких именно issue идет речь?
Есть вопрос по поводу пункту 14, а именно Fatal ошибки. Под fatal подразумевается deadlock, out of memory , out of index и тд или просто серьезные ошибки, после которых надо закончить функцию/горутину?
Так как если это именно fatal ошибка (например deadlock), то как вообще можно делать какой-то дополнительный детализированный вывод помимо стандартного?
Оформление и название супер))
Как пример: удобен при реализации обращений к бд на большие объемы данных, где используется SQL вида:
c yield:
без yield:
В случае без yield логику выбора последнего id необходимо будет вынести в место вызова функции из-за чего код может выглядеть менее красивым/читабельным :)
Так же можно дополнительно сэкономить время, если выполнять запрос через PreparedStatement в функции генераторе. Это можно, конечно же, реализовать и через return, но опять же через yield это будет сделать проще/читабельней.
Статья хорошая, но есть вопрос :)
Почему стоит задокументировать и не возвращаться? Можно поподробнее раскрыть предложение, что имелось в виду.
мне кажется самый попсовый проект на go это go : D
можно еще добавить кэширование днс запросов на какое-то время, как это сделано в fasthttp:
https://habr.com/ru/post/443378/