Обновить
20
Владислав@Akina

Сетевой администратор

0,9
Рейтинг
11
Подписчики
Отправить сообщение

Ой, да ради бога.. можно даже ничего не указывать - секрета-то здесь никакого нет.

Это баг

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

Блин, чем блокировать 92% VPN, лучше бы сразу опубликовали список тех VPN, которые входят в оставшиеся 8%. Народ бы быстренько на них пересел, и требуемые 92% были бы достигнуты сами собой, без дохреналионных бюджетных трат и вообще без каких-либо телодвижений..

Сюрприз. PostgreSQL такое не понимает. Хотя по идее всё разумно.

Да нет тут ничего разумного. И вы дальше даже сами объясняете, по какой именно причине.

При наличии ORDER BY / LIMIT в UNION правило архипростое. Есть скобки - применяется к подзапросу, нет скобок - ко всему запросу, если в тексте последнего подзапроса, иначе ошибка синтаксиса.

Подвох: если первая часть нашла запись, то после UNION ALL получится 2 строки (найденная + NULL-fallback), а внешний LIMIT 1 обрежет до первой. Но порядок строк в UNION ALL без явной сортировки не гарантирован. То есть теоретически вы можете получить NULL-строку даже когда лид существует.

Читаем правило выше и составляем правильный запрос:

(
    SELECT summary, escalation_reason, created_at FROM leads
    WHERE session_id = '...'
    ORDER BY created_at DESC LIMIT 1
)
UNION ALL
(
    SELECT NULL::text, NULL::text, NULL::timestamptz
)
ORDER BY created_at NULLS LAST -- вот он, фикс
LIMIT 1

Если первый подзапрос вернул запись, то ORDER BY, применяемый к объединённому набору записей, сначала вернёт запись с имеющимся значением поля, и только после неё запись со значением NULL. NULLS LAST в данном случае формально необязателен (но обязателен, если присутствует DESC - такова особенность сортировки у Postgres), но и беды от него никакой, а, поскольку сортируется не более 2 записей, то на производительность это не влияет.

Обрамление ВСЕХ подзапросов скобками делает запрос ну совсем корректным. Хотя (опять же формально) обрамление скобками у последнего подзапроса можно и опустить. Но я советую делать наоборот, и каждый подзапрос обрамлять скобками, даже если у вас ни ORDER BY, ни LIMIT не присутствуют.

А тот, кто придумал продакшен-базу и бэкапы хранить на одном томе - он кто?

Я ЛОХ, меня развели в максе

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

А со всем остальным согласен.

CDC:

The virus occurs worldwide, and most people become infected with EBV sometime during their lives. In the United States, as many as 95% of adults between 35 and 40 years of age have been infected.

Перевод:

один из самых распространённых в мире; считается, что он присутствует в организме 95% взрослых

Тьфу!

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

Она демонстрирует, что синтез последовательности ДНК, соответствующей последовательности аминокислот в пептиде, по крайней мере, в принципе, возможен.

Даже если брать исключительно основны́е аминокислоты, на 20 аминокислот приходится 61 кодон (плюс три терминирующих). И только две аминокислоты кодируются однозначно, всем остальным соответствуют как минимум два различных кодона. Иными словами, преобразование мРНК => белок необратимо.

Но даже если сказать, что это всё фигня, и главное - получить обратно последовательность нуклеотидов, которая кодирует исходный белок, то всё одно маловато будет. Далеко не факт, что построенная таким образом мРНК, формально кодирующая тот же белок, будет физически пригодна для его синтеза. Иная структура (вторичная, третичная) в теории может привести вообще к невозможности использования полученной мРНК как матрицы для синтеза белковой молекулы - кто знает, как её перекрутит да раскорячит в пространстве. Так что нужно как минимум практически показывать, что возможен цикл мРНК <=> белок вне зависимости от того, какая из кучи возможных мРНК получена на очередном шаге, а если в процессе будут получаться неработоспособные мРНК, то ещё и что процесс не зайдёт в тупик. Даже чисто статистически.

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

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

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

  1. Для проверки требуется регистрация. Обязательно. Иначе не работает. Хоть бы обмолвились о том..

  2. Совершенно безобразно работает с алиасами. Точнее, просто игнорирует их, и всё рвётся вместо присвоенных алиасов таблиц воткнуть полное исходное имя. Из-за чего просто невозможно нормально вводить текст.

Ну умеет... только с выходом в полпроцента - и это в считай тепличных условиях. Так что это не более чем курьёз.

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

Мой квайн моделирует не клеточную репликацию, а минимальный самовоспроизводящийся объект.

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

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

квайн моделирует ту самую задачу, которую решает живая клетка, т.е. самокопирование.

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

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

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

Скажите с российским зеркалом так же?

Ну на этот вопрос для Хрома я смогу ответить нескоро - я ж при написании комментария заглянул на все упомянутые сайты, так что все скрипты у меня в кэше лежат, и проверить получится лишь когда они там вылежат свой срок.

Впрочем, есть же другой браузер (Edge). На нём зеркало открылось сразу, оригинал - только во второй копии, песочницы - с первого раза. Так что боюсь, что дело не в доступности и скорости загрузки скриптов, а в каком-нить ТСПУitM..

От 30% моей аудитории из РФ стали приходить сообщения: «Сайт открывается только через VPN».

Я в РФ, но наблюдал гораздо более интересную (и непонятную для меня - не силён в вебе) картину. Причём на всех сайтах - и на SQLize, и на PHPize, и на SQLtest.

Открываешь ссылку (без VPN, использую Хром) - смотришь на белый экран. Лезешь в загруженный текст страницы - обнаруживаешь, что сама страница загружена, а бОльшая часть её скриптов, которые должны отрисовать страницу или что-то на ней - нет. Тут же в новой вкладке открываешь ссылку ещё раз - и она (с ну очень большой вероятностью, почти наверняка) открывается быстро и без проблем, а через пару секунд прогружается наконец и первая копия. Теперь в течение достаточно долгого времени (пока не закроешь все окна Хрома и ещё плюс минимум час) все ссылки будут открываться влёт. А потом придётся опять сплясать с бубном. В очень редких случаях, когда не срабатывает вторая копия - срабатывает третья. Чтобы не отработала и третья тоже - пока не встречалось.

автору указали на неточности, автор принял к сведению

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

А негатив... ну наверное это негатив от снижения уровня на Хабре в общем, который копится-копится, а потом просто выплёскивается на отдельных авторов, порой и правда в несколько увеличенном объёме.

1
23 ...

Информация

В рейтинге
2 303-й
Откуда
Зеленоград, Москва и Московская обл., Россия
Дата рождения
Зарегистрирован
Активность