Pull to refresh
3
0
Конторович Андрей @Kant8

User

Send message

Согласен, удался на славу. Теперь я точно знаю, чьи курсы я буду рекомендовать избегать.

NT Object Manager гуглить вероятно нужно, хотя мне как-то мало полезной инфы выдает на первых строчках
Начать лазить видимо можно оттуда docs.microsoft.com/en-us/sysinternals/downloads/winobj и оттуда docs.microsoft.com/en-us/windows-hardware/drivers/kernel/object-directories
Они распространяются на один единственный метод (Main) на всю программу. И добавили их фактически чтобы всякие однофайловые лямбды писать было проще без лишних отступов, ну и для обучения, по вкусу. Какие тенденции, какие потери структурированности, вообще не понятно.
Ну собственно если в коде проверяется, что файл есть и доступен, а потом в момент открытия это неожиданно стало не так, то вот и ИСКЛЮЧИТЕЛЬНАЯ ситуация. Зачем ее обрабатывать как-то особенно, всё равно ничего не сделать, кроме как попытаться опять, и потом уже кидать ошибку наверх. Можно сразу кидать ошибку, пусть наверху разбираются с повтором.
Увы, нет. Для структур
Cast<TResult>
вообще не работает, тк он внутри фактически делает
return (TResult)(object)x;


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

Условно говоря Cast несмотря на своё название вообще ничего не кастит, а лишь удостоверяется, что все элементы коллекции имеют нужный тип.
А зачем что-то где-то вручную ставить? В 99% случаев все Async методы EF вызываются исключительно с await. А уж если программист сделал два подряд FirstOrDefaultAsync и не подождал первый await'ом, то он сам себе злобный буратино, что ж тут поделать.

Task.WaitAll может вообще понадобиться только в каких-то достаточно экзотических случаях, когда надо условно сделать запрос по сети и почитать из базы, и ты знаешь, что и то и другое долго, а запросы не зависят друг от друга и их можно сделать параллельно. Для чисто работы с базой код пишется так же, как если бы он писался синхронным, только всё возможные методы меняются на их *Async друзей, и перед ними ставится await. На этом все преобразования можно закончить, и никаких ошибок не будет. Программа просто сможет продолжать делать что-то абсолютно другое из другого запроса, а не зависнет всеми потоками в ожиданиях чтения из базы/по сети.
Асинхронность != параллельность.
await дает потоку, отправившему запрос в базу, вернуться в пул и начать выполнять что угодно другое. А потом какой-то поток, может даже тот же, вернется получить результаты запроса.
В один момент времени с контекстом как работал один поток, так и продолжает.
Почти с самого начала сижу на тестовых сборках, падал браузер у меня только из-за различных комбинаций багов с девтулзами, которые чинились через пару дней. Собственно браузер не падал ни разу, только были зависания из-за наличия на странице тегов video с ссылками на протухшие видео, но это проблема была у всех хромобраузеров.
Эпл конечно всегда славилась своей эээ… щедростью к ценам. Но подставка для монитора за $1000 это уже что-то за гранью добра и зла.
Так с задачами то проблемы, каждый запрос надо рассматривать отдельно. А в общем виде правило достаточно тривиально — всё, что проверяется в запросе и имеет высокую селективность, должно быть помазано индексом. Ну и что порядок колонок в индексе имеет основополагающее значение.
Дальше чаще всего оптимизатор сам разберется, разве что с покрывающими индексами по крайней мере SqlServer любит перебдеть сильно в своих хинтах о индексах.
Сомневаюсь, что это дело обозримого будущего. Как и все нейронки эти боты просто опыт в чистом виде, они не думают. Увеличить пул героев до текущей сотни с мелочью и боты просто вообще не будут знать, что им делать, тк они не будут знать, какой путь ведет к победе.

Игра в компании с людьми это отлично показала, боты нормально играли только с ботами, кооперация с людьми стремилась к нулю либо приводила к печальным последствиям.
Из деталей могу сказать, что это ПО для небольшого банка, там секционированием и шардированием заниматься на текущий момент избыточно, дедлоки вылетают нечасто, и скорее всего когда из-за сбоев в статистике некоторые планы становятся параллельными со сканами там, где не нужно, и висят такие в кэше, пока мы не замечаем проблемы.
Ну и из того, что я не понимаю, в репортах таких круговых дедлоков всегда присутствуют типы ожиданий e_waitPortOpen и e_waitPipeGetRow. И если второй это из параллелизма, то откуда первый не совсем понятно.
Сейчас вот подумываю может попробовать поиграться с параллелизмом как описано в статье, но немного страшновато :)
А изоляция уже давно на снепшотах, если вы про это.
1224 — Отключает укрупнение блокировок на основе количества блокировок.

Контролирует ли этот флаг выбор между блокировками строк и страниц?
Периодически ловим дедлоки, где 3-5 не связанных друг с другом логически процессов по кругу лочатся из-за обновления строк в одной и той же таблице, находящихся похоже на одной странице. И непонятно как их побороть.
Или может какой-нибудь другой флаг или настройка могут помочь. В попадающейся в отчете дедлока хранимке уже давно написан rowlock, но он похоже игнорируется, плюс его нет в сотнях других запросов, которые приходят через ормку из приложения.
И как оно предполагается работать для склеивания?
То, что упоминается в статье, очевидно вызывает лоадер для дочерних коллекций после того, как был загружен родитель, иначе ему просто нечего передать как параметр хоть и в промис. В такой схеме даже теоретически невозможно поклеить всё в один запрос, только если самому всё распарсить, но собственно зачем тогда нужен QraphQL?

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

Даже в упомянутом Dataloader в описании пример с юзером, топ 5 друзей и лучшим другом у каждого юзера, где обещают не более 4 запросов (вместо 13), когда ормка превратит это в 1 или 2, в зависимости от реализации 1 к N.

Про кэши и ORM вообще не понял, причем тут они. Кэши прикручиваются куда угодно без особых проблем, паттер репозиторий в помощь или что угодно другое. Ормка лишь источник данных, кого дергать это проблемы конкретного проекта и конкретного случая.
Не видел ни одной статьи, где описывалось бы как это нормально сделать. Предлагают только вместо выполнения одинаковых запросов складывать их в некий батчер, который должен догадаться, что вот это надо бы кучкой выполнить. И пляски с бубном как это прикрутить к QraphQL чтобы он и не заметил.
Типа вот medium.com/slite/avoiding-n-1-requests-in-graphql-including-within-subscriptions-f9d7867a257d

Причем эта особенность рубит на корню использование GraphQL где-либо кроме сайтика на 10 человек. В статье героически ускорили с 20 секунд до 200 миллисекунд, а это всего лишь один подзапрос, а таких могут быть десятки. Не говоря уже о том, что ORMки для реляционных баз как минимум все 1 к 1 склеят в один единственный запрос, а тут их всё равно будет много.
Лучше бы Гугл купил наконец одну из компаний, которые уже 10 лет уверяют, что у них есть революционная технология производства энергоемких батарей, и им надо вот чуть чуть.
Её инженеры перенесли в облако веб-сайт, платформу для бронирования билетов и другие пользовательские сервисы. Это позволило перевозчику в два раза сократить время разработки функциональности

Это как так получилось? Облака стали реализовывать функциональность за заказчика?
Ну и вообще технически у белорусского паспорта нет серии. PP это просто часть номера, в самом паспорте уже давно нет даже слова Серия нигде, не то что отдельного поля.
ИЕ так сильно впаяно в винду, что не удивительно, что подпись какого-то кода ядра могла поменяться. Объем памяти уже интересней, возможно как раз чинили дыру рядом с «оптимизациями» в зависимости от количества оперативки. И так починили, что кирпичится.
Когда уже в этой вселенной перестанут делать круглыми элементы интерфейса, при учете что сетка всё равно как была квадратной, так и осталась.

Information

Rating
Does not participate
Location
Минск, Минская обл., Беларусь
Date of birth
Registered
Activity