Скорее всего не стоит постоянно логировать каждый request. Достаточно иметь возможность проброса, который будет работать в режиме debug. Хотя это уже зависит от задач.
Использовал бы для логирования всей цепочки запросов к микросервисам.
т.к не всегда понятно на каком этапе/микросервисе произошла ошибка. А имея идентификатор запроса инициированного на API Gateway, можно гараздо проще разобраться с проблемным местом.
Соглашусь с комментаторами выше, почему на 404 GET запросе происходит insert?
Если вы пишите свою систему статистики посещений, то:
во-первых не стоит записывать каждый HTTP запрос (Это уже не статистика а логгер, который легко настроить на HTTP сервере).
во-вторых исключите обработку своим index.php запросы на статику по паттернам (прим. /assets/*, /favicon.ico, /robots.txt, /sitemap.xml), даже если файлов таких нет, в дальнейшем вы избежите подобных проблем.
в-третьих никакого двойного трафика нет, у вас так-же происходят запросы на получение js, css и т.п
.З.Ы. Помню была немного похожая ситуация с хромом:
Писал платежные шлюзы которые тестировались через GET запрос аля: http://{ip}/gatewayName.php?params....
через какое-то время обнаружил что один шлюз начал переодически самопроизвольно запускаться, после долгого исследования обнаружил что хром добавил url в стартовую панель и переодически пытался обновить preview страницы.
ИМХО: статья не правильная была выбрана для перевода.
> Note the syntax isn’t the usual double pipe || operator that we associate with or, rather a single pipe | character.
> You might argue that every function should return something, if only a boolean to indicate successful execution, but that’s another discussion for another day.
Если сортировать по parent_id такой проблемы не должно случиться.
Но я согласен это не совсем true way.
с другой стороны я не вижу проблемы в рекурсии на стороне приложения.
Работоспособность не проверял, но думаю суть вы поймете.
$commentsTree = [];
$links = [];
foreach($comments as $comment){
if(array_key_exists($links, $comment['parent_id'])){
$parentComment = &$links[$comment['parent_id']];
$children = &$parentComment['children'][];
$children['comment'] = $comment;
$children['children'] = [];
}else{
$commentsTree[$comment['id']][];
$parentComment = &$commentsTree[$comment['id']];
$parentComment['comment'] = $comment;
$parentComment['children'] = [];
$links[$comment['id']] = &$parentComment;
}
}
всего в один проход мы можем собрать дерево, с учетом того что линейный набор данных отсортирован по parent_id или по дате.
//По id корня
SELECT
id, parent_id, root_id, comment
FROM comments
WHERE root_id = {id} OR id = {id}
//По id дочернего элемента
SELECT
id, parent_id, root_id, comment
FROM comments
WHERE root_id = (SELECT root_id FROM comments WHERE id = {id}) OR id = (SELECT root_id FROM comments WHERE id = {id})
Если пугаетесь вложенных запросов во втором случае, то можно оформить в виде процедурки с 2 запросами.
Хорошо, предлагаю решение проблемы дабы избежать рекурсивность.
Как правило в случае с комментариями необходимо иметь возможность получать полное дерево от корневого комментария или от дочернего зная его id.
проблему решить достаточно просто, вот пример таблицы:
id | parent_id | root_id | comment | name ...
В данном случае parent_id это всего лишь указатель структуры дерева не играющий роль при выборке полного дерева.
А root_id указатель на корневой комментарий позволяющий выбрать все дерево одним запросом.
Данный подход так же избавит от минуса NestedSets.
Но на mysql кастыль построить дерево
Дерево из однородных данных(комментарии в данном случае) в реляционных бд строится достаточно просто и без костылей.
table comments
id
parent_id
…
Что в дальнейшем позволяет сортировать как угодно, получать все комменты одного автора, считать количество и т.п
Не вижу в этом костылей ИМХО.
Извиняюсь за глупый вопрос,
Но зачем писать тест для уже работающего кода с использованием тестовых данных которые явно(судя по гифке) дают успешный результат?
.З.Ы. К сожалению еще не довелось писать тесты и хотелось бы прояснить данный вопрос.
Скорее всего не стоит постоянно логировать каждый request. Достаточно иметь возможность проброса, который будет работать в режиме debug. Хотя это уже зависит от задач.
Использовал бы для логирования всей цепочки запросов к микросервисам.
т.к не всегда понятно на каком этапе/микросервисе произошла ошибка. А имея идентификатор запроса инициированного на API Gateway, можно гараздо проще разобраться с проблемным местом.
Соглашусь с комментаторами выше, почему на 404 GET запросе происходит insert?
Если вы пишите свою систему статистики посещений, то:
.З.Ы. Помню была немного похожая ситуация с хромом:
Писал платежные шлюзы которые тестировались через GET запрос аля:
http://{ip}/gatewayName.php?params....через какое-то время обнаружил что один шлюз начал переодически самопроизвольно запускаться, после долгого исследования обнаружил что хром добавил url в стартовую панель и переодически пытался обновить preview страницы.
> Note the syntax isn’t the usual double pipe || operator that we associate with or, rather a single pipe | character.
> You might argue that every function should return something, if only a boolean to indicate successful execution, but that’s another discussion for another day.
usage: |
Use this annotation to declare a test case.
You may apply this annotation multiple times per location.
А почему необходимо придумывать языки для описания REST API?
Разве с этим не справится JSON?
Какие преимущества это дает?
.З.Ы. в общем одни вопросы.
Но я согласен это не совсем true way.
с другой стороны я не вижу проблемы в рекурсии на стороне приложения.
перед }else{
забыл дописать:
$links[$comment['id']] = &$children;
$commentsTree = [];
$links = [];
foreach($comments as $comment){
if(array_key_exists($links, $comment['parent_id'])){
$parentComment = &$links[$comment['parent_id']];
$children = &$parentComment['children'][];
$children['comment'] = $comment;
$children['children'] = [];
}else{
$commentsTree[$comment['id']][];
$parentComment = &$commentsTree[$comment['id']];
$parentComment['comment'] = $comment;
$parentComment['children'] = [];
$links[$comment['id']] = &$parentComment;
}
}
всего в один проход мы можем собрать дерево, с учетом того что линейный набор данных отсортирован по parent_id или по дате.
SELECT
id, parent_id, root_id, comment
FROM comments
WHERE root_id = {id} OR id = {id}
//По id дочернего элемента
SELECT
id, parent_id, root_id, comment
FROM comments
WHERE root_id = (SELECT root_id FROM comments WHERE id = {id}) OR id = (SELECT root_id FROM comments WHERE id = {id})
Если пугаетесь вложенных запросов во втором случае, то можно оформить в виде процедурки с 2 запросами.
Как правило в случае с комментариями необходимо иметь возможность получать полное дерево от корневого комментария или от дочернего зная его id.
проблему решить достаточно просто, вот пример таблицы:
id | parent_id | root_id | comment | name ...
В данном случае parent_id это всего лишь указатель структуры дерева не играющий роль при выборке полного дерева.
А root_id указатель на корневой комментарий позволяющий выбрать все дерево одним запросом.
Данный подход так же избавит от минуса NestedSets.
Дерево из однородных данных(комментарии в данном случае) в реляционных бд строится достаточно просто и без костылей.
table comments
id
parent_id
…
Что в дальнейшем позволяет сортировать как угодно, получать все комменты одного автора, считать количество и т.п
Не вижу в этом костылей ИМХО.
Но зачем писать тест для уже работающего кода с использованием тестовых данных которые явно(судя по гифке) дают успешный результат?
.З.Ы. К сожалению еще не довелось писать тесты и хотелось бы прояснить данный вопрос.