Какие сочные самоговорящие слова!

Английский точно был спроектирован инженером. Напоминает систему команд x86 с префиксами. Только в нем максимальное количество префиксов - 3. Will have been being done и иже даже у нативов вызывает buffer overrun, и поэтому не используется - точность адресации в страдательном залоге приносится в жертву краткости.

https://habr.com/ru/news/t/581248/comments/#comment_23549282

Ситуация настолько однозначная, что даже ассоциации оказываются идентичными :)

С языка сняли - я тоже первым делом подумал про "удочку"

«Если ты пьёшь с ворами - опасайся за свой кошелёк»

И оттуда же:

«Если ты ходишь по грязной дороге - ты не можешь не выпачкать ног»

Владимир Виссарионович

Вот это меганостальгический пост, и с такой широтой и глубиной подачи! Снимаю шляпу!

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

...значит, нужен гипер-флаг, говорящий о том, что удаление прилетело сверху, и computed-колонка, которая объединяет эти флаги по ИЛИ )

Знаете, что из всего этого следует? Что в отличие от хард, soft deletion - это бизнес-операция, а не техническая операция хранилища. И решать ее нужно, соответственно, на бизнес-, а не на техническом уровне. С той же статьей, например, комментарии к софтово-удаленной статье можно таким же образом софтово-удалить.

"Это скорее следствие легаси" - нет, к счастью. Если бы это было только необходимостью поддержания легаси, то множество новых фич, доступных только из-под кода БД, стремилось бы к нулю. Поскольку это не так, значит, существует способ работы с БД, отличный от ORM, для которого эти фичи разрабатываются. А поскольку разработка фичей стоит денег (и немалых), то за счет этих фичей производитель движка БД надеется получить конкурентное преимущество перед теми, у кого их нет. А раз эти фичи невозможно использовать посредством ORM, следовательно существует альтернативный способ работы с данными, используя эти фичи. Альтернативный ORM способ - это inner-base programmability (IBP).

"Изучите, как оно работает" - спасибо, я в курсе "thread-safe" поведения секвенсеров и identity :). Я имею в виду операции типа массовой вставки и получения обратно множества ключей, чтобы потом по ним связать и иерархические сущности. Эта задача нетривиальна даже для внутрибазного программирования, и скорее всего не реализована ни в одной ORM.

Говоря в более общем виде, в отличие от средств IBP, ORM не обладает полным информационным контекстом, и поэтому не может быть эффективна там, где обладание им критично по бизнес-логике или по эффективности (например, когерентные массовые апдейты)

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

PS - у меня дома стоит УЗМ-50, который заодно еще и защищает от перенапряжения (например из-за отгорания нуля в лестничном щитке) - за больше чем год ни одного ложного срабатывания от бытовых приборов (варить не пробовал ;)). Срабатывание именно на дугу проверял специально - через мощную лампу накаливания - детекция работает! Лампа прекрасно подходит, как низкоомная нагрузка при старте, и достаточно высокоомная, если вы замкнули проводник полностью, погасив дугу

Ассоциирование автора аллегории с субъектом, в ней описанным - довольно странная затея, более характерная для описанной Жванецким категории "Зачем спорить с хромым об искусстве, когда можно сразу ему сказать, что он хромой"

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

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

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

Предлагаю апнуть тему и синкануться по достигнутым результатам ;).

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

Еще из живых примеров из города Петра - за известного теперь всей России благодаря двойникам кандидата на одном из участков - 200 голосов, на соседнем - 2 (!). Едросовец при этом набирает ровно наоборот - похоже, между УИКами стоит молекулярная мембрана, которая фильтрует выгодные молекулярные формы от неугодных.

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

Если и так понятно, в какие таблицы смотреть, тогда зачем шарить множество ID по таблицам? Значит, все-таки существует кейз, когда непонятно? И что мешает, например, запустить identity-генератор в первой таблице с 1, во второй - скажем с миллиарда, а в третьей - с двух?

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

По поводу же велосипедов - тот же паттерн clas table inheritance при массовой вставке записей скорее всего будет нереализуем ни средствами ORM (она не догадается смапить множество новых ID), ни данным решением.(last_identity + 1 не даст гарантии на уникальный новый ID, если сиквенс параллельно дернет кто-то еще)

А как потом по Id узнать, в какой таблице экземпляр сущности? Делать выборку из всех с union?

Для Питона хочется сделать препроцессор, чтобы можно было писать в C-like нотации, которая одновременно и лаконичная, и четко визуально определяемая - но тогда Питон превратится в JavaScript ;)

С непривички глаз царапается двоеточиями там, где должно быть начало блока и этой ужасной концепцией отступов, как окончаний. Говорят, что очень сложно одновременно грамотно писать на русском и белорусском - так как правила правописания там полярны. Видимо после плотного питонизма автоматизм ставить закрывающие фигурные скобки тоже будет утрачен :)

Как говорят психологи - фантазии могут быть разные, но отклонением это называется только тогда, когда фантазии замещают сам объект. Можно иметь преференции по клавам, ностальгировать по типам пружинок, ходам, звукам и тактильности, и даже фанатеть от всего этого - но если при этом а) вы не можете работать на чём-то другом, б) считаете тех, кто может и/или работает людьми другого сорта - то это диагноз. Otherwise - просто преференция/ностальгия etc.

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