Архитектурное решение о котором вы не думаете

[@SergeyNemchinskiy]

До 50% скидки 🤑 на IT-курсы для начинающих и опытных программистов! Времени мало, скидка действует до 1 декабря - go.foxminded.ua/491PCQE

[@andrewolegovich8754]

Ось це ще одна віха крутого контенту. Не привʼязаний до мови, архітектурно направлений, актуальний. Дякую!

[@alexbozhko72]

Маэстро, Вы нас вообще ни в хр... ни в грош не ставите! Конечно же мы думаем о Concurrency на этапе проектирования. Просто потом забиваем на это на этапе разработки.

[@NemchinskyLive]

Ахаха, ну как на меня это ещё хуже)

[@LeonidYakovlev85]

Сергей и весь коллектив канала, запоздалое традиционное спасибо за выпуск, как всегда содержательно и интересно 👍👍👍

[@sanioksasha3338]

А как зовут автора, куда пропал Сергей Немчинский?

[@ИмяФамилия-э4ф7в]

1:03 - это что, для тебя, какая-то шутка?

[@ivanvint]

Это он перед сменой пола оставляет след в истории 😂😂😂

[@user-Leonidovich]

Да что вы беспокоитесь, он же не Вася, который уехал в Таиланд

[@totrovoleg2269]

Да нет, не переживайте, это всё ещё Сергей Немчиский

[@falikisrael4322]

Немчин Сергейский

[@pizdatyeTanci]

"Offline" здесь относится к способу, которым транзакции обрабатываются без немедленного обращения к серверу. Это означает, что информация об изменениях блокируется или обновляется локально, а затем синхронизируется с сервером позже. Представьте себе, если бы у вас был блокнот, куда вы вносили все изменения, а затем передавали его серверу для подтверждения, когда появляется интернет. Это полезно в условиях, где постоянное соединение с сервером невозможно. Does that make sense?

[@user-ffffffff]

В некоторых кейсах может помочь паттерн event sourcing. Очень хорошее решение когда много изменений от разных пользователей у сложного объекта. В придачу получаем лог изменений этого объекта. Но его прям с осторожностью нужно использовать. А так чаще всего обычного круда без блокировок заглаза.

[@borisisavnin9983]

Категорически приветствую! Сергей и его команда, спасибо огромное, родные!) ❤

[@jgkdmdevienjjgg8866]

Можно при первых изменениях пессимистично блочить кст. Чтобы просмотр не блочил. Ну или по кнопке режим редактирования. Также можно на вебсокеты подвязать и валидировать захват блокировки. Если поля перестаются меняться и пользователь заснул - снимать лок по таймауту с запросом о продлении юзеру. Я таких систем не делал, просто предполагаю.

[@Feell70]

Со стороны пользователя ПО скажу почему 1. Локакть - может бытьплохо 2. Локать - не выход. 1. Например в CRM менеджер зашёл в карточку клиента, переписывается с ним неспеша, а потом вообще не закрывает её... переписывает в блокнот цифры 20 минут. А руководителю отдела или администратору системы нужно что-то поправить в полях клиента - неа, не смогут, даже будучи админами. А чтобы так не было - нужно 10 костылей, которые будут сбоить. 2. Директ.Коммандер в Яндекс.Директе. Можно угандошить десятки часов работы над рекламной кампанией, если скачать её в первый день публикации, а потом через год не обновив с сервера данные например... изменить бюджет на 10%... Эти долбоящеры уже минимум 10 лет не могут сделать, чтобы как у Гугла в Эдвордсе передавались только изменённые поля, а не затиралось вообще всё, ещё и выдав ошибку и не передав нужное изменение... Тупо локи на мой взгляд мало где полезны, чаще нужно думать, как выстроить работу пользователей, чтобы не допускать конфликты.

[@jgkdmdevienjjgg8866]

@@Feell70 думаю тут речь о том что лучше уж плохой лок (оптимистичный), чем нежданчик с затиранием часовой работы. А так, если есть время, конечно делать более сложные решения, настроенные на конкретную ситуацию лучше. Но это делать дороже и риск допустить ошибку выше чем в топорных простых решениях.

[@БорисОстроумов-т7к]

Я делаю иначе, я просто логирую все изменения и записываю, кто их внес, потом быстро можно откатить миграцию к конкретным изменениям конкретного пользователя. Либо смержить, как в гите. Самое простое, это лочить при использовании, типа над документом работают, но это путь слабых кодеров. Хардкор, это дать работу сотне пользователей над одним документом и научиться с этим работать

[@andreychiglintcew5024]

❤ это прям реальность. У вас больше одного ядра? У вас есть асинхронность и конкурентность тоже)

[@gnidkoav]

Очень важная тема! к сожалению приходил к этому сам... )

[@muksaflash]

Круто сделано в гугл документах. Там в реальном времени видны исправления другого пользователя, и если он афк, его вроде выкидывает оттуда.

[@MrCri5py]

Но как это называется?

[@otvertka7070]

​@@MrCri5py Real-time веб-приложение, по идее. Оно обычно работает на веб-сокетах

[@kitten-free]

@@MrCri5py онлайн-редактирование?

[@Alexvilg]

Вебсокеты

[@megaman13able]

@@MrCri5py CRDT это называется)

[@EwwwGeN]

Хотелось бы послушать про всякие событийные паттерны, которые как раз-таки и нацелены на то, чтобы предотвращать проблемы с одновременной записью, а так же помогать работе распределенных систем

[@kan4317]

Есть какое нибудь API, которое будет отдавать булево значение, является ли автор все еще Сергеем Немчинским?

[@NemchinskyLive]

Return true; не благодарите)

[@Gruberhoff]

Потрібно ще мати на увазі що поки ви перевіряєте чи змінилась версія документа в бд, то в цей момент її може оновлювати хтось інший. тобто потрібно використовувати тейбл лок

[@kitten-free]

офлайн называется потому что позволяет редактировать офлайн. т.е скачал, ушёл в офлайн, правишь, вернулся в онлайн, сохранил. если же есть возможность оставаться онлайн то можно отображать правки онлайн мгновенно по мере их внесения всеми участниками как это сделано например в гугл доках

[@pasha5760]

Можливо в назві говориться, що це "офлайн" блокування тому що колієнт має скачати і вести зміни у себе на локальній машині, а на сервері сам об'єкт який піддається змінам не може знаходиться (бо там знаходться тільки вже збережені обєкти) і сама мітка блокування об'єкту (а це вже трози інше)

[@nikolaiii3]

В ТортойзСВН случай когда двое копаются в одном файле очень неплохо разруливался при попытке коммита. Последний должен был всё порешать, правильно расположить изменения.

[@ukrainetoday960]

Самое оптимальное - это лог чейнджей или же ревизия контента - нажал пользователь на редактирование - оповестил всех кто уже редактирует этот контент, сохранил поля - изменения отобразились у других пользователей - с пометкой у поля кто его сделал - во всплывашке, нажал пользователь на поле для редактирования - у всех отобразилось во всплывашке кто редачит поле. Плюс у каждого поля должна быть кнопка сравнения значений и отката к какому либо предыдущему Если делать с локами то лучше так, редактирование - это запрос на анлок, пользователь нажал кнопку редактировать - у всех кто уже редактирует появилась кнопка отмены с таймером, не нажали на кнопку - сохранился их недописанный вариант - синхронизировались чейнджи - у пользователя кто запросил анлок - появилась возможность редактировать

[@ИмяФамилия-э4ф7в]

Смешно. Не, оно то может и удобно, но такая куча работы, запросов/перезапросов, да и хранить это все нужно, изменения там, текущие редакторы... И ради чего? Хорошее решение - это не то, которое даёт все и сразу. Хорошее решение - это то, которое даёт нужный результат за приемлемое время и бюджет. Ведь все эти "приколюхи" отнюдь не бесплатные. И если оно прямо надо для какого-то приложения - то да. А если "чтобы было" - то нет 😢

[@kitten-free]

"оптимальное" - это с точки зрения удобства пользования. но не пользователь решает а владелец. а для владельца оптимальное - это приносящее больше денег. т.е лучшее за свои деньги. обычно оптимальное - это вообще без управления параллелизмом - молчаливая перезапись

[@ukrainetoday960]

@@ИмяФамилия-э4ф7в то что кажется что здесь куча работы - лишь следствие непрофессионализма, такая архитектура решается в юи всего лишь двумя паттернами. Нет ничего страшного в том что нужно хранить чейнджи если этой о требует бизнес, экономия на спичках тут может обойтись дороже

[@ukrainetoday960]

@@ИмяФамилия-э4ф7в ради чего? Ради требований заказчика, хорошая архитектура это не когда тяп ляп сделал, авось потом переделают, а так чтобы у заказчика бизнес работал как швейцарские часики

[@ukrainetoday960]

@@kitten-free оптимально с точки зрения архитектуры, если тебе такое удобство заказал заказчик, если заказчику не нужно, то разумеется и архитектура такая не нужна.

[@geek-peek]

Есть крайне простое решение. Использовать PATCH вместо PUT. Отредактировал одно поле - Окей, мы поменяем только его. В простом круде этого достаточно. В сложном - serializable и доменные события

[@olegg7263]

Дякую за чергове цікаве відео! Правда в перший раз чую саме offline lock. Завжди було просто optimistic / pessimistic locking. Але це було зовсім в іншому контексті, а саме лок певних записів БД на час виконання транзакції. Там є ще поділ на pessimistic read (“сам можеш апдейтити, інші можуть тільки читати») та pessimistic write («тільки ти можеш читати і апдейтити, інші навіть читати не можуть, поки твоя транзакція не закомітиться/заролбечиться). У SQL для того є ще команди SELECT FOR SHARE / SELECT FOR UPDATE. А там далі, якщо накосячив із pessimistic writes, можуть виникати дедлоки в БД, ото фіксити веселуха ще та ))

[@fillfacks5986]

Фух, вы всё ещё Сергей Немчинский😅🎉

[@maksym7279]

Дякую!

[@alexblack43]

Так тут даже у одного пользователя могут быть проблемы. Открыл несколько страниц разных товаров инет-магаза в разных вкладках, подобавлял их в корзину и уже будет рассинхрон между той корзиной, которая была на самой старой вкладке, и той, которая на самой новой.

[@alexroberto8499]

Ох этот пенсионерский подход к построению UI. Петя обновил title, так что вперед Вася обновляйся чтобы обновить описание :D

[@lukivan8]

Триггерим сохранение на onсhange с большим дебаунсером (10 секунд). Вешаем пессимистичный лок который снимается если 5 минут не было изменений. Вопрос лишь в том что отправляется на сервер для минимизации перегонки данных

[@tretiakov7]

А как снимать лок, если пользователь просто так зашел и ничего не менял, а просто вышел? Например, пользователь зашел, по запросу опредлили его ид и залочили за ним область. А он просто закрыл вкладку в браузере, то как отследить, когда нужно снять лок?

[@alexandr3036]

круто а где про Архитектурное решение?

[@impl-life]

Ще є варіант як у Гугл документах, всі редактори можуть редагувати одночасно, і всі бачать зміни одне одного, хоч це і складніше реалізувати, і не всім воно треба)

[@TwilightSun32]

в песимістичному варіанті краще не на користувача а на сесію посилання зберігати, якщо є така сутність. можливо саме це й малося на увазі.

[@germanmalinovsky1719]

offline означает что блокировка происходит не в реальном времени, а локально на стороне клиента (клиент захватил блокировку и продолжает дальше работать без постоянного подключения), типа как при работе с git (децентрализировано) в противовес к svn (централизировано).

[@NemchinskyLive]

Это версия или официальная трактовка? В любом случае мне нравится

[@kitten-free]

гит не блокирует. оптимистичная - не блокировка. оптимистичное -управление параллелизмом. редактирование бывает офлайн и онлайн(как в гугл-доках). офлайн может быть с управлением параллельных правок либо без. без - это молчаливая перезапись. с управлением - бывает оптимистичное управление и бывает пессимистичное. оптимистичное не блокирует, редактирование происходит без блокировки. если кто-то успел вперёд тебя - ты получишь предупреждение. так работает в гите. пессимистичное управление параллелизмом - это монопольная блокировка.

[@germanmalinovsky1719]

@@kitten-free Cпасибо за дополнение. Да, гит не блокирует физически. Я думаю тут проблема в разбежности названия механизма с его идеей и уже конкретной реализации когда используется слово locking. Возможно выбрана плохая аналогия, но очень уж тот же процесс push ветки напоминает оптимистичную блокировку.

[@antonyurchenco1668]

@@NemchinskyLive imho и "не официальная трактовка" stateless приложение, которыми являются большенство web apps, раздают пользователям формы для редактирования и не следят за процессом на стороне клиента

[@kakao_with_milk]

Было решение лока такое. 1 открывает, создается временный файл, куда вносится изменения. При сохранении проверяется есть ли еще активные пользователи этого файла, и делается сравнение с побитовой версией, если изменений нет, то идет сохранение. Если есть, тогда делается побитовый compare , пользователь контролирует это. если в этот момент открытый документ у второго пользователя, то предлагается обновить файл, делается совмещение со смещением текущих изменений. А поскольку каждый работает с переодической версией, то мы имеем полный контроль над изменениями. В конце выводится результат слияния во временом файле, и последний кто сохраняет, смотрит все ли правильно

[@oleksandrsova4803]

Ви найголовнішого не розповіли - як тепер замовника переконати в тому, що йому це потрібно? Скоро вже чотири роки буде як я все намагаюсь підібрати кейси і уламати замовника на додачу обробки ETag та If-Modified - замовник прямо каже що йому те не потрібно. Тож я далеко не згоден з тейком про те, що ніхто про локи не думає і ще більше не згоден з тим, що така поведінка системи - це вина розробника.

[@AmirLT-x6y]

Intresting❤

[@pavelvasianovych4030]

Можно в пессимистической блокировке определить таймаут на случай уезда Васи в Тайланд. Кстати по поводу вебинара и тренинга интересует лимит желающих и стоимость.

[@blazheiko777]

как вариант сохранять изменения в объектах каждое поле отдельно и при сохранении поля заново обновлять все поля, вероятность, что два человека одновременно редактирую одно и то же поле сильно ниже.

[@kitten-free]

оптимистичная - не блокировка. оптимистичное - управление параллелизмом. редактирование бывает офлайн и онлайн(как в гугл-доках). офлайн может быть с управлением параллельных правок либо без. без - это молчаливая перезапись. с управлением - бывает оптимистичное управление и бывает пессимистичное. оптимистичное не блокирует, редактирование происходит без блокировки. если кто-то успел вперёд тебя - ты получишь предупреждение. так работает в гите. пессимистичное управление параллелизмом - это монопольная блокировка.

[@kitten-free]

Optimistic concurrency control (OCC), also known as optimistic locking, is a non-locking concurrency control method

[@STimothy]

Сергей, вы множетсво раз говорили, что магистр никому не нужен, и в Украине это и впрадву так. Но мне мои знакомые программисты говорят что если я в будущем буду устраиваться в иностранную компанию, то магистра иметь очень даже не плохо Это правда?

[@NemchinskyLive]

Смотря где) в Украине пофиг. А так зависит от страны

[@antikarch]

Решал описанную проблему с помощью вычисления диффов. Десять лет назад самому пришлось писать, а сейчас javers есть, кажется, с его помощью можно сделать дифф и накатить его на сущность. По итогу оптимистик или пессимистик лока нет, есть просто блокировка на работу с диффми и запись, чтоб гонки не было.

[@ИмяФамилия-э4ф7в]

9:50 ну я пока не вижу проблем с таким решением: за основу берем песимистик лок, но тот, кто второй открывает на редактирование, может снять этот лок просто в диалоговом меню. Ну и логгировать это дело. Тогда если будут перетирать друг другу, то это их проблемы. Тебе писали, что ресурс занят? Писали. Ну вот и нахрена ты тыкал "снять лок" и запартачил запись другому человеку? Или себе.

[@NemchinskyLive]

Не стоит так делать, не каждый бизнес одобрит такое

[@ИмяФамилия-э4ф7в]

@@NemchinskyLive очевидно, что решение нужно согласовывать с заказчиком. Это было бы мое первое предложение по реализации, и далее я бы ждал согласия или замечаний. Ведь доп. админка - удовольствие не бесплатное. Но если заказчик (или менеджер) скажет: "шед ап, анд тейк май мани", то кто я такой, чтобы ему отказывать?

[@kitten-free]

можно решение отдавать на откуп пользователю. например кнопка "залочить". не нажал её - значит правишь в надежде что успеешь сохранить первым. не хочешь рисковать - жмёшь её. другой может и может снятжь а может и не может. можно и права выдавать на снятие лока, можно вводить систему прав кто чей лок может снимать итд итп - усложнять можно до бесконечности. но - зачем? чаще всего вообще никакого управления параллельным доступом не требуется - тупая молчаливая перезапись

[@kitten-free]

звучит так как будто заказчик должен заранее решить какой тип лока ему нужен. но можно предложить такое решение пользователю: т.е пользователь может нажать кнопку "захватить" ресурс в монопольное пользование а может не нажимать и оптимистично редактировать в надежде что успеет сохранить первым. помимо этого есть ещё и онлайн-редактирование, в противоположность этим вашим офлайн-локам - это когда правки других пользователей мгновенно становятся видны каждому пользователю и каждый видит работу каждого в онлайн режиме (если они работают над одним файлом, причём видят кто именно делает что. в гугл-доках например именно так и сделали. но все эти решения стоят денег, скорее всего вашему заказчику они не нужны и ему подойдёт слепая перезапись а пользователи как-нибудь сами договорятся чтобы друг другу не мешать - обычно это оптимальное и самое дешёвое решение, экономное, то что нужно для бизнеса. можно ещё сделать журнал редактирования чтобы они могли видеть кто когда вносил правки и что поменялось

[@MasterSergius]

Конкьюренси... Можно попросить Вас прочитать bicycle и vehicle? Как раз подтягиваю английский, думаю, научусь и тут чему-нибудь...

[@alexandernaumochkin]

Тут тебе получится подтянуть только рунглиш :)))

[@Hi_Katy]

Сергей, kənˈkərənsē

[@Alandal-n3b]

Можно вас попросить сделать ролик о простом РАБОЧЕМ ДНЕ например Back-end Developer. Буквально от и до. Многим было бы интересно. И почему то этот тематический пробел никто не заполняет

[@hint1k]

7 часов думать, 1 час кодить :D

[@ZingeR325]

Оффлайн лок - полагаю, это связано с разрывом связи между базой и юзером (его интерфейсом и выборкой данных в него)

[@SergeyNemchinskiy]

Между заказчиком и разработчиком 👉 kzbin.info/www/bejne/r5ycg3Z9jJJ5hc0

[@kexforlecture]

О, мы как раз писимистик лок переделывали на оптимистик. А у них названия есть)

[@postoronny]

Мне скоро предстоит этим заниматься... Пока народ говорит: "вапще не надо, будем редактировать с одного места"... (предполагаемые конкуренты рядом за соседними компами) Причём, говорит это тот, кому и предстоит редактировать, хоть у него работы там и так по горло и, строго говоря, редактирование - это не его основная работа на этом месте. Мож сталкивался уже?..

[@oleksandrivashchenko7916]

Недавно столкнулся с проблемой конкурентной записи у себя на проекте. Мы решили через версионирование. Каждый раз когда клиент пытается сделать запись, он дополнительно отправляет версию на основании которой он делал изменения, и если эта версия не совпадает с текущей, мы ему сообщаем об этом и не даем сделать запись. Данный подход предупреждает перетерание данных, но он не дает никаких инструментов по решению конфликтов, справедливости ради, мы сознательно отказались от этого, решили что система решения конфликтов нам не нужна, достаточно будет детекции. Судя по всему это оптимистик лок

[@the_huge_knight]

Optimistic OFFLINE Lock

[@kitten-free]

это вообще не лок - вы ничего не лочите. вы оптимистично управляете конкурентностью. это optimistic concurrency control.

[@kitten-free]

Optimistic concurrency control (OCC), also known as optimistic locking, is a non-locking concurrency control method

[@Tahiaji]

Думали об этом (в плане что дело дошло дальше думания а хоть какой-то реализации) аж на одном проекте. Причем это вылезло из-за того, что фоновая задача после сохранения анализировала текст, извлекала теги и пересохраняла контент. А оказалось (внезапно), что админы могут что-то сохранить, потом вернуться назад и продолжить работу (да, даже на уровне одного пользователя). Итоговое решение - вывести всплывашку, что текущий контент кто-то поредактировал до вас. И уже пользователь принимает решение что делать дальше

[@lukivan8]

Вообще интересная идея для минимизации решений пользователя это обрабатывать конфликтуют ли диффы на сервере. Если изменения касаются разных частей то нам все равно и мы не беспокоим пользователя

[@Tahiaji]

@@lukivan8 дифы это немного на пару ступенек выше. Немного поковырялись в вариантах реализации (как это вообще делается) и поняли, что трудозатраты того не стоят.

[@narimz]

Лук топ 😎

[@TheAcekon]

А в чому проблема при Pessimistic Offline Lock не робити обмеження часу або якщо людина кілька годин не активна завершати його сеанс і знімати всі блокування.

[@kozakA8]

а если работа будет делаться 2 часа? Есть не только 2 варианта. До часу или уехал в Тайланд. Есть вариант 3 часовой работы например. Или дать человеку полдня на выполнение работы. Остальных предупредить что бы полдня занимались другим. Например работа с 10-14. Второй человек захотел зайти в 13:50(а вдруг уже первый всё сделал) И наткнулся та лок. В твоём предоложении лучше сменить час времени, на отрезок времени которое назначит админ

[@TheAcekon]

@@kozakA8 я про те що блок ставиться поки активний сеанс користувача і знімается розлогіном з системи.

[@komputersh4ik546]

​@@kozakA8ну можно сделать если человек например 1 час не вносит каких-то изменений, то выдавать сообщение на продолжение сессии этому человеку, если человек не подтверждает, то блокировка снимается автоматически

[@oneway2ba]

что такое версия? это просто счетчик условный который плюсуется при каждом редактировании или что-то более глобальное?

[@kitten-free]

да, в самом простом варианте - просто счётчик. при чтении он читается и отдаётся клиенту. при записи клиент сообщает какое у него число было - если на момент записи число поменялось - значит опоздал. в sql можно писать: update foo set bar=$bar, version:=$version+1 where id=$id and version=$version и если количество обновлённых строк=0 значит версия изменилась

[@WadeChannal]

Забавно, что я как раз на своем проекте сейчас решаю этот вопрос

[@Mr43046721]

Сегодня какой-то день блокировок. Часа 2 назад выступал с докладом про Постгрес, блокировки и транзакции вот это всё. Решил отвлечься в ютубчик - и тут про блокировки)))

[@shod76]

Можно сделать и без админки. Просто джоба сама будет снимать локи после определенного периода времени при отсутствии активности.

[@ИмяФамилия-э4ф7в]

@@shod76 не годится. Допустим, ты установил это время равным часу. Ок, Петя взял документ на редактирование, подправить две цифры, и у него сломался комп. Документ нужен через пол часа на совещание. Но подправить его можно через час. Удобно 👍

[@shod76]

@@ИмяФамилия-э4ф7в в админке только время блокировки сделать изменяемым для различных типов объектов. В данном редком случае зашел в админку поменял время блокировки на 1 мин и все ) потом вернул обратно. Но , соглашусь, с админкой лучше

[@РайанКупер-э4о]

Хотите concurrency - работайте с BEAM.

[@VitaliyParhomenko-w5b]

У нас вариант, когда песимистик лок удаляется автоматически через какое-то время, которого более чем хватает что бы отредактировать документ

[@sergeibatiuk3468]

Я начал о нем думать - и понеслось: Scala, Akka, Functional Programming, Cats Effect, Haskell, Project Reactor, Go routines

[@ukrainetoday960]

5:07 блокировки это не самое лучшее решение

[@ale-zhu]

В SAP поставил блокировку и нет проблем

[@sergeibatiuk3468]

Конкьюренси!

[@MasterSergius]

А-а-рон (Key and Peele - Substitute teacher)

[@ekari]

Ну я не знаю. Для Васи уехавшего в Тайланд достаточно установить разумные сроки времени редактирования. и никакая админка не нужна!

[@velsah5763]

В 1С эта проблема решена просто. Если кто-то открыл документ на редактирование- остальным он открывается ТОЛЬКО на просмотр. Но осталась проблема с отчетами. Есть отчеты , которые моут формироваться несколько часов- а за это время инфа может изменится. Вылезет бред (но обычно не критично)

[@indarelloivanov2180]

Ну так ситуация когда первый открыл документ на редактирование и пошел пить кофе, проблема как была так и осталась. При чем здесь открытие на чтение?

[@the_huge_knight]

фу 1С, там одни проблемы

[@0imax]

​@@indarelloivanov2180почему бы не пинать афк-шника через х минут?)

[@Андрей-к3ъ9е]

Если программистам нужно объяснять что такое блокировка,... то я понимаю, почему про программистов 1С говорят что они умнее прочих и почему программисты "правильных" языков так агрятся на 1С. Касательно отчетов на "несколько часов", если это системное, то у вас что-то не так работает.

[@velsah5763]

@@Андрей-к3ъ9е это не системное, но иногда случается. И если спросить у программиста в реальном бизнес-секторе, то он вам скажет, что иногда лучше сделать сейчас и рабочее решение, чем пару недель потратить на оптимизацию

[@AndriiGoogle]

А коли відео будуть вже українською?

[@АлексейН-р3т]

Когда спрашивать решили не человека, а программиста, я понял, что ничего не пойму. Внимательно посмотрел ролик и действительно ничего не понял.

[@Igr_Ok]

Админка - плохая идея. Я не завидую тому, кого разбудят в 2 часа ночи, чтоб разлочить документ. В программе можно отслеживать, работает ли юзер с документом. Если нет активности - закрывать его.

[@0imax]

По сути, это мердж конфликт, и решать можно подобным же способом.

[@ИмяФамилия-э4ф7в]

@@0imax ага, прямо вижу как бухгалтеры резольвят конфликты в документах 😏

[@0imax]

@@ИмяФамилия-э4ф7в Примерно так в своё время придумали 1С 😂

[@eugenstadnik1923]

Сбрасьівать локи после окончания рабочего дня.

[@jonkarmok1840]

А можно просто сохранять только то что пользователь поменял, не перетирать всю запись, а поменять только конкретные измененные поля тогда никакой проблемы не будет

[@kitten-free]

будет, просто гранулярность снизится. теперь затёртыми окажутся только конкретные поля целиком. а что если у вас в блоге запись - это блогпост. у блогпоста есть поля: автор, название, дата создания, обновления, содержимое поста. вот два автора поменяют запись - поменялись 3 поля: автор, дата, содержимое поста - почти вся запись затёрлась. потом вы решите вносить только конкретные строки внутри поля и ситуация повторится уже со строками. короче в конце вы изобретёте гит.

[@jonkarmok1840]

@@kitten-free ладно согласен, но есть еще вариант, когда редачим берем хеш записи, когда сохраняем, сервак проверяет, актуальная версия сходится с той которую мы начали редачить и если нет, сообщаем юзеру при сохраеении, и просим перенести правки в новую версию, это сильно проще гита, и сильно удобнее блокировок

[@kitten-free]

@@jonkarmok1840 вы описали оптимистичную блокировку с избыточным хешированием. то же самое можно сделать на банальном счётчике-инкременте. единственное отличие - ваша версия позволяет не выдавать предупреждение если новая версия совпадает полностью с прежней. что редко

[@jonkarmok1840]

@@kitten-free нет, я не предлагаю блокировать, я предлагаю сообщить пользователю актуальное состояние во время сохранения и попросить его перенести из в новую верси, тип 2 формы вывести актуальнкю и старую но с его изменениями

[@jonkarmok1840]

@@kitten-free инкремент звучит жидко, надо следить за актуальностью, с хешем проще

[@nahigor]

КонкАренсу, нет такого слова конкЮренсу.

[@TheNavalJack]

Мы в ex USSR, тут еще и судО (sudo), и стаг (stage), и секбрЭхи (security breach) есть))

[@sergeibatiuk3468]

Такое ощущение, что у него есть некоторое immutable property

[@qwertymangames1800]

Это всё ещё Сергей Немчинский?

[@vatakiller]

Честно говоря ничего нового для себя не подчеркнул. Как правило, более-менее опытный бэкендер это знает

[@YuriyStakhniak]

КонкАренсі😊

[@muksaflash]

А гугл переводчик там скорее у говорит, чем а 🤔

[@СлаваВолошин-ы3с]

@@muksaflash нет, с спецом его переслушал, там А

[@muksaflash]

@@СлаваВолошин-ы3с это зависит от диалекта, скорее всего. У меня на компьютере более похоже на «А», а на телефоне на «У» 😂.

[@КолёКолё-ю2щ]

@@muksaflash😅🔥

[@ДмитрийАнтоненко-л9з]

Маэстро, Вы нас вообще ни в хр... ни в грош не ставите! "Программисты", надо же! Не "программисты", а "бэкендеры". Какие несколько пользователей на фронтенде?! Какое concurrency!?

[@_dzen_tv_]

Учим новое слово - вылогонить

[@alexandernaumochkin]

Отлогонить. И по самые помидоры.

[@lexxryazanov]

@@alexandernaumochkin Залогинить и вылогаутить

[@nrmncr37]

что, так плохо с подписчиками, что надо выкладывать кликбейтное дерьмо?

[@ZingeR325]

И ещё одна похожая шляпа: рассинхронизация текущей выборки на экране у клиента реальному состоянию данных в базе. Рефрешить нонстоп нельзя, и потому юзер видит то, что было в базе на момент, когда он открыл форму. И вот он с чувством, с толком, с расстановкой выбирает себе запись для работы, открывает её, а она в этот момент УЖЕ изменена/удалена/невалидна. А узнает он об этом в лучшем случае (это если про "конкуренси" позаботились) - уже когда захочет сохранить свою стену текста, которую 40 минут вносил в документ 🤪 з.ы. Это отдельный случай, не описанный в сценарии "пессимистик лок". Речь о случае, когда документ никто не правит прямо сейчас - он его уже исправил, но мы этого не знаем, мы из базы прочитали старую версию.

[@ИмяФамилия-э4ф7в]

@@ZingeR325 если настроен пессимистик оффлайн лок, то такой ситуации не возникнет. Если я взял документ в работу, то в базе он лочится. Как его кто-то другой возьмёт в работу пока я не отпущу? И, соответственно, я не смогу взять в работу, если его кто-то залочил.

[@eduardvad]

Немчинский, чому не на мовi? Тебя в окопах ждут давно

[@omen9748]

Привет Наш Дорогой! Открой школу для русских! Это принцип? Если хочешь учи, преподавай! Спасибо! Вещаешь русским языком, странный ты. Открой школу. Если проблемы, с русскими не вещай на русском языке. Достал правда!

[@lexxkrt]

автор почему не в окопе? или ты настолько лживый патриот?

[@kolbasavert]

Я как бі не являюсь опытным програмистом но я у себя єто пишут так - поскольку изменение об'екта в одну и туже микро/нано секунду невозможно, запись будет отличаться по времени , и когда пользователь получает доступ к данным об'екта то он имеет их загруженную копию,а при загрузке измений я написал сравнение новой копии со старой , и если в каком то поле изменений нет то єто поле не обнавляется Или я шото не полял ? как то сложно тут вы придумали .