Pull to refresh
18
0
Денис Лимарев @peakle

Go/php разработчик

Send message

Рад что вам понравилось )

По поводу трассировки запросов, она есть, но в статье не описана. Так же у нас есть агрегирующий сбор статистики по 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:

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-трекере и никогда к нему больше не возвращаться

Почему стоит задокументировать и не возвращаться? Можно поподробнее раскрыть предложение, что имелось в виду.

мне кажется самый попсовый проект на go это go : D

можно еще добавить кэширование днс запросов на какое-то время, как это сделано в fasthttp:
https://habr.com/ru/post/443378/

отличный фактор кстати)) заставляет задуматься
Я не опровергаю, что создание ПО одиночками невозможно, но все же в компаниях как правило для создания продукта задействуют команду из нескольких людей, необязательно только разработчиков, и статья как раз о том какие принципы должны быть заложены в такой команде и чего стоит избегать.

Information

Rating
Does not participate
Location
Россия
Works in
Registered
Activity

Specialization

Backend Developer