Тоже ловил подобную багу (раз уж делимся опытом). В дебаге работает, в релизе иногда клиент падает, если сервер перезапускается, но в релизе с прицеплённым отладчиком всё идеально. Прицепление отладчика после падения приводит к различным местам, связанным с криптографией. Куча времени потрачено на синхронизацию, чистку объектов, а оказалось, что в нативном вызове чуть поменялась структура данных, и она портит память, но так, что стреляет только при таких условиях и совершенно в несвяазанном коде.
Такое число обязано существовать: из восьмидесяти русских букв и пробелов можно составить всего 3480 обозначений, значит, с использованием восьмидесяти букв можно обозначить не более 3480 чисел. Значит, некое число, не большее чем 3480, обозначить таким образом невозможно.
А если смысловое, то весь пассаж не имеет смысла, т.к. ваш же пример противоречит последней фразе.
Смотрите. У нас есть тридцатичетырёхричная система счистления (буквы русского языка + пробел). Условно говоря а — 0, я — 32. Соответственно «слово»: гад = 4 * 34 * 34 + 0 * 34 + 5
«Слово» одиннадцать тоже соответствует какому-то числу, как и слово жопа, как и слово то число которое нельзя называть записать. И даже если в рускком языке слово кажется осмысленным, оно имеет совершенно конкретное значение, соответствующее единственному числу согласно правилам записи таких чисел.
Не понял порадокса с 80 буквами. Если мы определяем запись числа буквами, то фраза самое маленькое число, для обозначения которого недостаточно восьмидесяти букв будет соответвовать какому-то конкретному числу из этой записи, а не смыслом, который в нём читается. Иначе получается, что одними и теми же символами мы можем одновременно записать разные числа — что не способствует конструктивным построениям.
В качестве примера, часто использующееся DEADBEEF, которые означает конкретное число 3735928559, а не кусок говядины, случайно обнаружившийся в компьютере.
А тогда ещё учтите, что чек в магазине он не за бумагу, на которой он напечатан. и 248 тыс. рублей это не прибыль магазина. Это плата за товары, которые не продадутся сегодня, продадутся завтра. Т.е. в реальности надо брать где-нибудь 10% от этой суммы, и числа уже не такие интересные, да?
И это тоже, как показатель «крутости» технологии :)
Но в целом, у меня через Хром на андроиде работает, с кучей вариантов авторизации. На компьютере просит специальную флешку.
С профилями как-то уж больно спешили. У существующего профиля даже аватарку не сменить.
Девтулзы вы будете чинить, или это не приоритет (просто нет смысла писать баги, если нет желания их править)?.. Банально не работает аудит и device toolbar
Какая-то странная экономия, если честно. Перед тем как сэкономить, надо купить весьма приличный компьютер (чтобы M.2 поддерживал, да не одно), потом сэкономить в этом дорогом компьютере на памяти, залезать в итоге в Swap, что не очень хорошо, даже если он быстрый. При этом не обязательно покупать QLC (выбрали уж самый плохой вариант), можно поискать MLC, гораздо большего объёма, который при частичном использовании весьма неплохо будет себя чувствовать.
Т.е. получается что у нас дорогая железяка, которая всё время лезет в своп (настолько, что SSD убивает), и всё ради небольшой экономии…
Это плохое решение. Пользователь может не на обед, а куда-то убежать по делам (любимый хомячок простудился) и банально позвонить другому с просьбой доделать. Может просто случайно нажать какую-то кнопку (сохранять не планировал) и уйти домой. В небольшой организации это может решиться организационными методами и пенделями работникам, но больше шансов, что пендели получать разработчики.
Хуже будет, если пользователь 1 открыл форму и ушёл на обед
Что вы тут предлагаете? Не давать редактировать форму никому, или просто сделать хороший код, который это как-то обрабатывает. Второй подход отличный, но очень дорогой в плане времени программистов (форм много, все разные, ситуация не очень частая).
В MSSQL есть столбец типа timestamp (и нет, там не время). В результате при любом обновлении записи значение этого столбца меняется автоматически. Ничего не надо считать ручками, нельзя забыть его обновить. В postgre для этих целей можно использовать xmin, но он считается не очень труЪ способом.
А смысл этого действия? Форму открыли два пользователя в 12:00. Редактируют, первый сохранил в 12:05, второй в 12:10 и затёр все действия первого. Чем нам в этой ситуации поможет SELECT FOR UPDATE?
Не стоит это использовать для данной задачи.
Представьте, пользователь открывает форму на редактирование и… уходит на обед. Строчка залочена. Больше никто не может ничего с ней сделать.
Ну а что делать, если в PG нет встроенных средств :( Если использование сущности ограничено, то можно и своё версионирование написать, но потом придёт какой-нибудь разработчик, и забудет в каком-нибудь апдейте проинкрементить версию. В результате всё замечательно «сломается», хотя работать будет, но будет бага вида «у меня пропали данные», которую вообще не возможно будет отследить.
Уж лучше всё упадёт при обновлении и можно накрыть это костылями, чем будет странно себя вести из-за ошибки программиста в каком-нибудь второстепенном модуле.
— Как проверять, когда со строкой работают несколько пользователей? Какие варианты есть?
В MSSQL есть столбец типа timestamp, в pg можно заюзать xmin, например. Отдаём на форму его значение, при апдейте проверяем не только ключ, но и сравниваем с xmin. Если кто-то изменил строчку — не обновим ничего, сообщаем пользователю (а он уж пусть решает, насильно перенакатить, бросить всё, попытаться смёржить).
Тут уж больно минимальные. Оценить конкретные стоимости seq/random/cpu/memory можно только на своей железке. И какой-нить pg_tune --analyze был бы очень полезен.
А сейчас вся эта оценка перекладывается на админа, а разработчики постгре умывают лапки.
А если смысловое, то весь пассаж не имеет смысла, т.к. ваш же пример противоречит последней фразе.
«Слово» одиннадцать тоже соответствует какому-то числу, как и слово жопа, как и слово то число которое нельзя
называтьзаписать. И даже если в рускком языке слово кажется осмысленным, оно имеет совершенно конкретное значение, соответствующее единственному числу согласно правилам записи таких чисел.В качестве примера, часто использующееся DEADBEEF, которые означает конкретное число 3735928559, а не кусок говядины, случайно обнаружившийся в компьютере.
Но в целом, у меня через Хром на андроиде работает, с кучей вариантов авторизации. На компьютере просит специальную флешку.
Девтулзы вы будете чинить, или это не приоритет (просто нет смысла писать баги, если нет желания их править)?.. Банально не работает аудит и device toolbar
Т.е. получается что у нас дорогая железяка, которая всё время лезет в своп (настолько, что SSD убивает), и всё ради небольшой экономии…
Что вы тут предлагаете? Не давать редактировать форму никому, или просто сделать хороший код, который это как-то обрабатывает. Второй подход отличный, но очень дорогой в плане времени программистов (форм много, все разные, ситуация не очень частая).
Представьте, пользователь открывает форму на редактирование и… уходит на обед. Строчка залочена. Больше никто не может ничего с ней сделать.
Уж лучше всё упадёт при обновлении и можно накрыть это костылями, чем будет странно себя вести из-за ошибки программиста в каком-нибудь второстепенном модуле.
В MSSQL есть столбец типа timestamp, в pg можно заюзать xmin, например. Отдаём на форму его значение, при апдейте проверяем не только ключ, но и сравниваем с xmin. Если кто-то изменил строчку — не обновим ничего, сообщаем пользователю (а он уж пусть решает, насильно перенакатить, бросить всё, попытаться смёржить).
А сейчас вся эта оценка перекладывается на админа, а разработчики постгре умывают лапки.