Соответственно, никаких опор в состоянии невесомости быть не может
Я именно это и написал в предыдущем комментарии. Там прямо есть такая фраза "никакой опоры быть не может". Непонятно, зачем вы мне ее повторяете и что хотите этим доказать.
Тела в искривленном пространстве движутся по геодезическим вместо прямых.
Яблоко, висящее на ветке, движется по геодезической со скоростью 0. И пока на него не подействует сила, которая создаст ускорение, скорость останется 0.
Опора мешает движению, компенсируя движение по геодезической силой реакции опоры.
Представим, что яблоко в невесомости из моего предыдущего комментария покрыто липкой жидкостью и прилипает к ткани, а ткань достаточно тяжелая. Тогда геодезическая будет направлена вдоль поверхности ткани. Вы толкнули яблоко, оно покатилось по геодезической в центр вогнутости. Вы подставили ладонь, создали опору, опора создала силу, сила создала ускорение, яблоко остановилось (изменило скорость до 0), то есть опора компенсировала движение. Если вы теперь уберете ладонь, яблоко не начнет катиться дальше по геодезической, так как на него не действуют силы. Геодезическая при этом остается искривлена. Аналогично с гравитацией, только в 3 измерениях. Яблоко может изменить скорость с "0" до "не 0" только если на него действует какая-то сила, которая создает ускорение.
Я вам именно про это и говорю. Если гравитация не создает силу, а просто искривляет пространство, то это ничем не отличается от невесомости, и никакой опоры быть не может. Вы поместили лист ткани в невесомость, положили яблоко на край, потом создали вогнутость в ткани, яблоко не покатится в направлении вогнутости. Понятие опоры подразумевает действие силы, потому что опора создает противодействующую ей силу.
Но оно не движется по геодезической, оно находится неподвижно в одной точке геодезической, неважно насколько она искривлена. Если вы уберете опору в невесомости, оно не начнет двигаться в сторону где была опора. Если мы говорим, что опора постоянно компенсирует движение, значит предполагаем, что движение постоянно есть, значит есть сила, которая его создает.
Если вы имеете в виду, что Земля движется в пространстве, и яблоко движется вместе с ней, то из этого следует, что на планете, неподвижно висящей в центре Вселенной, яблоко падать не будет, что выглядит крайне маловероятным.
Я не упрощал ОТО до визуализации, это вы предложили поискать наглядные видео. Есть широко распространенное утверждение "Гравитация это не поле, она не действует на тела, а просто искривляет пространство", я указал на то, что оно не объясняет начало движения в искривленном пространстве. "Гравитация искривляет движение во времени, превращая его в движение в пространстве" объясняет, тут согласен. Но все равно есть вопрос, как она его искривляет, если это не поле. Значит есть искривляющая сила, и значит есть поле, которое ее создает.
Они рисуют разное искривление в начале и в конце падения яблока, что неправильно в любом смысле. Искривление в любой момент одинаково, потому что массы тел одинаковые. Также они показывают движение линий пространства к Земле, о чем я и говорил в предыдущем комментарии. Если что-то двигается из-за гравитации, значит гравитация это обычное поле, аналогично постоянному магниту, а не искривление. Идея, что часть движения во времени конвертируется в движение в пространстве и накладывается на уже существующее движение, выглядит интересно. Также это объясняет замедление времени из-за гравитации. Но тогда надо говорить, что гравитация искривляет только время, а не пространство. Иначе, как мне кажется, величина "дельта скорости в единицу времени" не была бы константой, на нее накладывалось бы искривление самого пространства.
Предполагается, что гравитация искривляет пространство, а не двигает его. Если считать, что пространство двигается вниз из-за гравитации, тогда гравитация это обычное поле.
материя и энергия искривляют ткань пространства-времени
Концепция искривления не объясняет, почему яблоко, неподвижно висящее в искривленном пространстве на яблоне, вдруг начинает падать (т.е. двигаться вниз).
Лиго может зарегистрировать проехавшую рядом бетономешалку, не обмениваясь с ней фотонами
Фотон это колебание электромагнитного поля. А Лиго измеряет колебания гравитационного, ну или можно сказать гравитационно-временного. То есть это аналог фотона, только в других полях.
В этом случае нужна компенсирующая операция, если не удалось заблокировать продукт
Да не нужна там никакая операция) Просто создавать UpdateRequest и обновлять Product нужно в одной транзакции, они для этого и придуманы. Статус OnReview это денормализация INSERT в таблицу review/update_request. Если под блокировкой вы подразумеваете блокировку от редактирования с помощью установки статуса OnReview, то это не будет работать. Оба процесса прочитают текущий статус, который еще не OnReview, потом сначала первый поставит OnReview без ошибок, потом второй.
Ну и запрос нельзя обрабатывать, пока не подтверждена блокировка товара
А можно просто не отправлять его на обработку в другую систему до корректного сохранения данных) Тем более что это прямо написано в бизнес-требованиях.
Я не говорил что аналитики должны работать с историей событий непосредственно
Зато я говорил. Аналитики хотят изучать статистику с помощью SQL-запросов, для этого им нужно текущее состояние сущностей, бизнес не хочет дергать программистов на каждый запрос, который им захотелось написать один раз.
да я и не уверен что даже в этом случае вас удастся в чем-то убедить
Так это я хочу убедить вас или хотя бы других, что код в этом случае становится менее поддерживаемым)
если вам интересен пример реализации чего то посложнее
Да у нас один из сервисов сейчас сделан с Event Sourcing, это было неправильное решение, от него куча проблем.
Хочу посоветовать не повышать карму этому аккаунту выше 0. Может это реальная история, а может бот для накрутки кармы. Советы в комментариях можно и так написать. Подозрительно выглядит описание "Мне сказали самой все изучать, но я не буду, дайте мне другой совет".
Напишу совет на случай, если история реальная, или другим новичкам кто в поиске найдет. Вам правильно сказали, берете и делаете. Ищете в интернете "android hello world", пробуете руководства по порядку пока не получится. Как получилось что-то запустить, пробуете добавлять взаимодействия - кнопки на экране, реакции на касания, анимации интерфейса и т.д. Потом можно попробовать сделать какую-нибудь игру - тетрис, змейка. Если вообще опыта с программированием нет, лучше начать с консольных программ для ПК, на языке где есть классы - C#, Java, PHP, последовательность действий та же.
Нет, в этих методах мы можем делать проверку assertIsEditable() и бросать исключение если редактирование продукта заблокировано.
При чем тут заблокированное редактирование) Я же написал далее "поставить пустое описание в любом сценарии", а это разрешено только в сценарии создания. Подразумевается, что само редактирование разрешено, а проверять надо длину описания.
Я бы вместо дополнительного статуса просто добавил бы свойство isEditable
Бизнес хочет статус, но принципиально это ничего не меняет, просто вместо int надо записывать bool. Если мы управляем состоянием Product снаружи, то логика находится не в сущности.
Я бы сказал создает eventual consistency, но насколько я понял это и так происходит
Нет, тут будет именно race condition. Первый процесс создал UpdateRequest, а статус "На проверке" еще не поставил. Второй проверяет статус, он не "На проверке", значит можно создавать UpdateRequest, и тоже создает. С отдельным обработчиком событий, тем более асинхронным, это невозможно предотвратить.
Можно повесить обработчики событий которые создадут специальную проекцию (денормализированную таблицу в базе)
Ну вот ProductChange это и есть специальная таблица)
когда есть полная история событий, которые публикуют агрегаты
А аналитики как должны с базой работать?) Как делать фильтры типа "Показать заявки, где меняется категория"? История событий без финального состояния применима только в очень ограниченных ситуациях. Тем более что пользователь может 100 раз поменять описание, прежде чем отправить на проверку, зачем хранить эти промежуточные значения. Хранить diff изменений "было-стало" это основное назначение Review/UpdateRequest, он больше ни для чего не нужен, это сущность из бизнес-требований.
Получить эти данные из продукта через outside.
Ну получили вы, а дальше-то что?) Надо на них наложить изменения и получить финальное состояние товара, которое надо проверять на соответствие критериям. То есть у вас будет структура, дублирующая Product, или вообще нетипизированный хешмап. Ну понятно, если создать сущность Product2, то в исходном Product логику писать не нужно.
Вот поэтому, чтобы сравнивать подходы, и нужен полный код со всеми слоями и несколькими действиями, а не гипотетическое обсуждение. Если есть желание, пишите статью со своей реализацией, сравним. Если нет, не вижу смысла переливать из пустого в порожнее)
Первая система только для пользователей-поставщиков, менеджеры работают только в другой внутренней системе, куда отправляется UpdateRequest. Пользователи в своей системе не могут редактировать товар на проверке. В рамках примера можно считать, что менеджеры не могут редактировать товар поставщика кроме как через принятие UpdateRequest, для этого и нужна процедура проверки. В дальнейшем они могут попросить возможность менять значения в UpdateRequest.
Тогда это будут просто сеттеры, и можно будет привести Product в любое состояние без соблюдения инвариантов, чего с логикой в сущностях мы хотим избежать. Например, поставить пустое описание в любом сценарии, потому что при создании это разрешено.
Товар тогда вообще ничего не знает о этих , апдейт реквкестах.
Товар не может совсем не знать, у него есть статус "На проверке", при котором запрещено редактирование, он устанавливается одновременно с созданием UpdateRequest. Значит в Product как минимум должен быть метод, который его устанавливает. Из UpdateRequest мы его вызывать не можем, потому что это другой агрегат, значит надо делать доменный сервис. А это в свою очередь создает вопрос, что если кто-то поставит этот статус напрямую без вызова доменного сервиса. То есть та же ситуация, как и с логикой в сервисах. Замена доменного сервиса на обработчик событий ничего не меняет, а также создает состояние гонки, когда UpdateRequest уже создан, а статус в Product еще не поставлен.
почему UpdateRequest не может хранить значения полей товара
Теоретически это возможно, но практически очень неудобно. Нам пришлось бы создавать UpdateRequest при первом изменении, и он бы висел в системе месяцами, пока пользователь не захочет отправить на проверку в другую систему, с соответствующим различием в датах создания. Это не отражает реальные процессы. Статусы Created и Sent для него имели бы специальные значения, при открытии страницы просмотра товара надо было бы искать в истории последнюю запись для этого товара в одном из этих статусов, чтобы наложить изменения, это создает лишнюю нагрузку на базу.
Для обработки UpdateRequest удобнее видеть diff, а для просмотра товара удобнее финальные значения. Например, было 10 изображений, 1 добавили, 2 удалили. В UpdateRequest будeт 3 записи вида {id: 123, url: '...', action: DELETED}, а в ProductChange список из 9. Иначе в UpdateRequest придется хранить 10+9 записей, чтобы можно было просмотреть diff позже. С проверкой тоже непонятно, в UpdateRequest одна запись с удалением изображения, как без данных из Product проверить ограничение "Для отправки на проверку должно быть описание не менее 300 символов, и хотя бы 1 изображение".
ProductChange это дежурные изменения, UpdateRequest это запрос на их проверку. Как коммит и мерж-реквест.
Так как вы проапдейтите-то?) Для этого должен быть метод в Product. Метод acceptChangesFromReview это и делает, там другой логики и нет.
А чтобы создать ProductUpdateRequest/Review, надо сначала накопить новые значения полей, которые надо отправлять. Это делает метод edit, который записывает их в ProductChange. ProductUpdateRequest не может их хранить, у него другой бизнес-процесс, он отражает запрос в другую систему и создается только при отправке, к нему привязываются комментарии, хранится история таких запросов, и т.д. Вот из этих методов логика в Product и состоит, ее никак не убрать.
В нашем реальном приложении ProductCreationRequest существовал только в другой системе, при принятии она отправляла данные товара в нашу через API, и нам надо было только фактически создать товар. Поэтому я в примере рассмотрел только эту часть. Но в создании действительно почти нет логики, надо просто передать нужные данные в конструктор Product. А вот с изменением уже не так все просто. Вся логика, которая у меня находится в классе Product, связана с внесением изменений в сам агрегат Product, это те методы, который вы будете вызывать из подписчиков событий.
Спасибо за примеры. То, что вы называете ProductChangeRequest, это и есть Review в моем примере. Для создания товара у нас в реальном приложении тоже был похожий механизм, просто я решил не делать пример еще больше, и сделал только точку, которая могла бы вызываться при принятии ProductCreationRequest.
Можно логику sendForReview поместить и в Review, а не в Product, но статус товара все равно надо менять, потому что так хочет бизнес.
Ну и если честно для меня в вашем коде сложно понять, где реализована та или иная часть из бизнес-требований. Например, я вижу, что создание товара у вас не реализовано, и непонятно, где именно надо написать new Product(), если бы у меня была такая задача.
Так вроде же очевидно, если они не знают вас кроме как по комментам на этом сайте, то у них личная неприязнь к вашей точке зрения, которую вы высказываете в этих комментах.
Насчет комментариев я бы еще предложил починить эту штуку. Открыл страницу, прочитал комментарии за 10 минут, на какой-то решил ответить. Отвечаешь, и все новые комментарии за эти 10 минут помечаются прочитанными, хотя на страницу после добавления они не подгружаются. То есть при обновлении страницы они показываются уже прочитанными.
Я именно это и написал в предыдущем комментарии. Там прямо есть такая фраза "никакой опоры быть не может". Непонятно, зачем вы мне ее повторяете и что хотите этим доказать.
Яблоко, висящее на ветке, движется по геодезической со скоростью 0. И пока на него не подействует сила, которая создаст ускорение, скорость останется 0.
Представим, что яблоко в невесомости из моего предыдущего комментария покрыто липкой жидкостью и прилипает к ткани, а ткань достаточно тяжелая. Тогда геодезическая будет направлена вдоль поверхности ткани. Вы толкнули яблоко, оно покатилось по геодезической в центр вогнутости. Вы подставили ладонь, создали опору, опора создала силу, сила создала ускорение, яблоко остановилось (изменило скорость до 0), то есть опора компенсировала движение. Если вы теперь уберете ладонь, яблоко не начнет катиться дальше по геодезической, так как на него не действуют силы. Геодезическая при этом остается искривлена. Аналогично с гравитацией, только в 3 измерениях. Яблоко может изменить скорость с "0" до "не 0" только если на него действует какая-то сила, которая создает ускорение.
Я вам именно про это и говорю. Если гравитация не создает силу, а просто искривляет пространство, то это ничем не отличается от невесомости, и никакой опоры быть не может. Вы поместили лист ткани в невесомость, положили яблоко на край, потом создали вогнутость в ткани, яблоко не покатится в направлении вогнутости. Понятие опоры подразумевает действие силы, потому что опора создает противодействующую ей силу.
Но оно не движется по геодезической, оно находится неподвижно в одной точке геодезической, неважно насколько она искривлена. Если вы уберете опору в невесомости, оно не начнет двигаться в сторону где была опора. Если мы говорим, что опора постоянно компенсирует движение, значит предполагаем, что движение постоянно есть, значит есть сила, которая его создает.
Если вы имеете в виду, что Земля движется в пространстве, и яблоко движется вместе с ней, то из этого следует, что на планете, неподвижно висящей в центре Вселенной, яблоко падать не будет, что выглядит крайне маловероятным.
Я не упрощал ОТО до визуализации, это вы предложили поискать наглядные видео. Есть широко распространенное утверждение "Гравитация это не поле, она не действует на тела, а просто искривляет пространство", я указал на то, что оно не объясняет начало движения в искривленном пространстве. "Гравитация искривляет движение во времени, превращая его в движение в пространстве" объясняет, тут согласен. Но все равно есть вопрос, как она его искривляет, если это не поле. Значит есть искривляющая сила, и значит есть поле, которое ее создает.
Они рисуют разное искривление в начале и в конце падения яблока, что неправильно в любом смысле. Искривление в любой момент одинаково, потому что массы тел одинаковые.
Также они показывают движение линий пространства к Земле, о чем я и говорил в предыдущем комментарии. Если что-то двигается из-за гравитации, значит гравитация это обычное поле, аналогично постоянному магниту, а не искривление.
Идея, что часть движения во времени конвертируется в движение в пространстве и накладывается на уже существующее движение, выглядит интересно. Также это объясняет замедление времени из-за гравитации. Но тогда надо говорить, что гравитация искривляет только время, а не пространство. Иначе, как мне кажется, величина "дельта скорости в единицу времени" не была бы константой, на нее накладывалось бы искривление самого пространства.
Предполагается, что гравитация искривляет пространство, а не двигает его. Если считать, что пространство двигается вниз из-за гравитации, тогда гравитация это обычное поле.
Концепция искривления не объясняет, почему яблоко, неподвижно висящее в искривленном пространстве на яблоне, вдруг начинает падать (т.е. двигаться вниз).
Для компенсации этого в них соответственно замедляется время.
Фотон это колебание электромагнитного поля. А Лиго измеряет колебания гравитационного, ну или можно сказать гравитационно-временного. То есть это аналог фотона, только в других полях.
Да не нужна там никакая операция) Просто создавать UpdateRequest и обновлять Product нужно в одной транзакции, они для этого и придуманы.
Статус OnReview это денормализация INSERT в таблицу review/update_request.
Если под блокировкой вы подразумеваете блокировку от редактирования с помощью установки статуса OnReview, то это не будет работать. Оба процесса прочитают текущий статус, который еще не OnReview, потом сначала первый поставит OnReview без ошибок, потом второй.
А можно просто не отправлять его на обработку в другую систему до корректного сохранения данных) Тем более что это прямо написано в бизнес-требованиях.
Зато я говорил. Аналитики хотят изучать статистику с помощью SQL-запросов, для этого им нужно текущее состояние сущностей, бизнес не хочет дергать программистов на каждый запрос, который им захотелось написать один раз.
Так это я хочу убедить вас или хотя бы других, что код в этом случае становится менее поддерживаемым)
Да у нас один из сервисов сейчас сделан с Event Sourcing, это было неправильное решение, от него куча проблем.
Хочу посоветовать не повышать карму этому аккаунту выше 0. Может это реальная история, а может бот для накрутки кармы. Советы в комментариях можно и так написать. Подозрительно выглядит описание "Мне сказали самой все изучать, но я не буду, дайте мне другой совет".
Напишу совет на случай, если история реальная, или другим новичкам кто в поиске найдет. Вам правильно сказали, берете и делаете. Ищете в интернете "android hello world", пробуете руководства по порядку пока не получится. Как получилось что-то запустить, пробуете добавлять взаимодействия - кнопки на экране, реакции на касания, анимации интерфейса и т.д. Потом можно попробовать сделать какую-нибудь игру - тетрис, змейка. Если вообще опыта с программированием нет, лучше начать с консольных программ для ПК, на языке где есть классы - C#, Java, PHP, последовательность действий та же.
При чем тут заблокированное редактирование) Я же написал далее "поставить пустое описание в любом сценарии", а это разрешено только в сценарии создания. Подразумевается, что само редактирование разрешено, а проверять надо длину описания.
Бизнес хочет статус, но принципиально это ничего не меняет, просто вместо int надо записывать bool. Если мы управляем состоянием Product снаружи, то логика находится не в сущности.
Нет, тут будет именно race condition. Первый процесс создал UpdateRequest, а статус "На проверке" еще не поставил. Второй проверяет статус, он не "На проверке", значит можно создавать UpdateRequest, и тоже создает. С отдельным обработчиком событий, тем более асинхронным, это невозможно предотвратить.
Ну вот ProductChange это и есть специальная таблица)
А аналитики как должны с базой работать?) Как делать фильтры типа "Показать заявки, где меняется категория"? История событий без финального состояния применима только в очень ограниченных ситуациях. Тем более что пользователь может 100 раз поменять описание, прежде чем отправить на проверку, зачем хранить эти промежуточные значения.
Хранить diff изменений "было-стало" это основное назначение Review/UpdateRequest, он больше ни для чего не нужен, это сущность из бизнес-требований.
Ну получили вы, а дальше-то что?) Надо на них наложить изменения и получить финальное состояние товара, которое надо проверять на соответствие критериям. То есть у вас будет структура, дублирующая Product, или вообще нетипизированный хешмап. Ну понятно, если создать сущность Product2, то в исходном Product логику писать не нужно.
Вот поэтому, чтобы сравнивать подходы, и нужен полный код со всеми слоями и несколькими действиями, а не гипотетическое обсуждение. Если есть желание, пишите статью со своей реализацией, сравним. Если нет, не вижу смысла переливать из пустого в порожнее)
Первая система только для пользователей-поставщиков, менеджеры работают только в другой внутренней системе, куда отправляется UpdateRequest. Пользователи в своей системе не могут редактировать товар на проверке. В рамках примера можно считать, что менеджеры не могут редактировать товар поставщика кроме как через принятие UpdateRequest, для этого и нужна процедура проверки. В дальнейшем они могут попросить возможность менять значения в UpdateRequest.
Тогда это будут просто сеттеры, и можно будет привести Product в любое состояние без соблюдения инвариантов, чего с логикой в сущностях мы хотим избежать. Например, поставить пустое описание в любом сценарии, потому что при создании это разрешено.
Товар не может совсем не знать, у него есть статус "На проверке", при котором запрещено редактирование, он устанавливается одновременно с созданием UpdateRequest. Значит в Product как минимум должен быть метод, который его устанавливает. Из UpdateRequest мы его вызывать не можем, потому что это другой агрегат, значит надо делать доменный сервис. А это в свою очередь создает вопрос, что если кто-то поставит этот статус напрямую без вызова доменного сервиса. То есть та же ситуация, как и с логикой в сервисах. Замена доменного сервиса на обработчик событий ничего не меняет, а также создает состояние гонки, когда UpdateRequest уже создан, а статус в Product еще не поставлен.
Теоретически это возможно, но практически очень неудобно. Нам пришлось бы создавать UpdateRequest при первом изменении, и он бы висел в системе месяцами, пока пользователь не захочет отправить на проверку в другую систему, с соответствующим различием в датах создания. Это не отражает реальные процессы. Статусы Created и Sent для него имели бы специальные значения, при открытии страницы просмотра товара надо было бы искать в истории последнюю запись для этого товара в одном из этих статусов, чтобы наложить изменения, это создает лишнюю нагрузку на базу.
Для обработки UpdateRequest удобнее видеть diff, а для просмотра товара удобнее финальные значения. Например, было 10 изображений, 1 добавили, 2 удалили. В UpdateRequest будeт 3 записи вида {id: 123, url: '...', action: DELETED}, а в ProductChange список из 9. Иначе в UpdateRequest придется хранить 10+9 записей, чтобы можно было просмотреть diff позже. С проверкой тоже непонятно, в UpdateRequest одна запись с удалением изображения, как без данных из Product проверить ограничение "Для отправки на проверку должно быть описание не менее 300 символов, и хотя бы 1 изображение".
ProductChange это дежурные изменения, UpdateRequest это запрос на их проверку. Как коммит и мерж-реквест.
Так как вы проапдейтите-то?) Для этого должен быть метод в Product. Метод acceptChangesFromReview это и делает, там другой логики и нет.
А чтобы создать ProductUpdateRequest/Review, надо сначала накопить новые значения полей, которые надо отправлять. Это делает метод edit, который записывает их в ProductChange. ProductUpdateRequest не может их хранить, у него другой бизнес-процесс, он отражает запрос в другую систему и создается только при отправке, к нему привязываются комментарии, хранится история таких запросов, и т.д. Вот из этих методов логика в Product и состоит, ее никак не убрать.
В нашем реальном приложении ProductCreationRequest существовал только в другой системе, при принятии она отправляла данные товара в нашу через API, и нам надо было только фактически создать товар. Поэтому я в примере рассмотрел только эту часть. Но в создании действительно почти нет логики, надо просто передать нужные данные в конструктор Product. А вот с изменением уже не так все просто. Вся логика, которая у меня находится в классе Product, связана с внесением изменений в сам агрегат Product, это те методы, который вы будете вызывать из подписчиков событий.
Спасибо за примеры. То, что вы называете ProductChangeRequest, это и есть Review в моем примере. Для создания товара у нас в реальном приложении тоже был похожий механизм, просто я решил не делать пример еще больше, и сделал только точку, которая могла бы вызываться при принятии ProductCreationRequest.
Можно логику sendForReview поместить и в Review, а не в Product, но статус товара все равно надо менять, потому что так хочет бизнес.
Ну и если честно для меня в вашем коде сложно понять, где реализована та или иная часть из бизнес-требований. Например, я вижу, что создание товара у вас не реализовано, и непонятно, где именно надо написать
new Product(), если бы у меня была такая задача.Так вроде же очевидно, если они не знают вас кроме как по комментам на этом сайте, то у них личная неприязнь к вашей точке зрения, которую вы высказываете в этих комментах.
@powerman@mike_shapovalov Было бы интересно узнать ваше мнение, если я в чем-то ошибся) Что думаете? Можно было что-то сделать по-другому?
Насчет комментариев я бы еще предложил починить эту штуку. Открыл страницу, прочитал комментарии за 10 минут, на какой-то решил ответить. Отвечаешь, и все новые комментарии за эти 10 минут помечаются прочитанными, хотя на страницу после добавления они не подгружаются. То есть при обновлении страницы они показываются уже прочитанными.