Телеграмм чат группы dotnet

Провожу завтра в 11:00 мск по YouTube
Мастер-класс "Эффективность разработчика".
Участие свободное.
Подробности https://t.me/developer_school_chat/3437

Дмитрий Полянин in Школа разработчика

Мастер-класс "Эффективность разработчика. Методы повышения эффективности, и анализ существующих проблем."
Пройдёт 10 октября, 11:00 МСК .

Вы сталкивались с ситуацией, когда делаете проект, сил уходит много, а результата мало и проект стоит на месте или двигается очень медленно?

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

Темы:
🌱 Принцип Парето 80% - 20%. Принцип Парето в квадрате.
🌱 Ошибка программистов: чрезмерное углубление и рекурсия.
🌱 Расскажу свой epic fail опыт по этой теме и выводы из него.
🌱 Метод расстановки приоритетов задач с помощью маркеров важности 1-3.
🌱 Что такое зависание на задаче и методы переключения и сброса для выхода из зависания
🌱 Поэтапность и своевременное закрытие каждого этапа. К чему приводят незакрытые (зависшие) задачи.

Для записи поставить + комментарием.

источник

08:32пожаловаться #4

NK

ID:0 in var chat = new Chat();

На работе у нас есть некое подобие самописной ORM, работающей напрямую с ADO.NET и одна из проблем с которой мы сталкивались при её разработке - это то, что у количества параметров используемых в DbCommand есть лимит, этот лимит накладывается базой данных и у разных баз данных он разный.

Например, у PostgreSQL в каждом SQL statement (под SQL statement имеется в виду то, что в разговорной речи называют SQL запросом) может использоваться не больше 65535 параметров (в одну DbCommand можно отправить множество SQL statement и таким образом в общем DbCommand может содержать больше 65535 параметров).

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

Первым делом я конечно же полез смотреть как эту проблему решает и решает ли вообще Entity Framework...

Написал небольшую заметку о том, можно ли при использовании Entity Framework столкнуться с ограничениями, которые накладывает использование DbCommand под его капотом:⁠ Entity Framework и ограничения DbCommand

Бояринцев .NET

Entity Framework и ограничения DbCommand

На работе у нас есть некое подобие самописной ORM, работающей напрямую с ADO.NET и одна из проблем с которой мы сталкивались при её разработке - это то, что у количества параметров используемых в DbCommand есть лимит, этот лимит накладывается базой данных и у разных баз данных он разный. Например, у PostgreSQL в каждом SQL statement (под SQL statement имеется в виду то, что в разговорной речи называют SQL запросом) может использоваться не больше 65535 параметров (в одну DbCommand можно отправить множество SQL statement и таким образом в общем DbCommand может содержать больше 65535 параметров). В большинстве запросов довольно сложно преодолеть разрешённую планку, мы столкнулись с этим ограничением в двух случаях - в INSERT, когда за один запрос вставляется множество строк: INSERT INTO table_name (column_namе(s)) values (value1, ...), (valueN, ...), ... Если таблица содержит 10 столбцов, то с проблемой мы столкнёмся уже при попытке вставить за один раз 656 строк. И в запросах с использованием оператора IN: SELECT…

источник

09:33пожаловаться #5

D

Dmitriy in var chat = new Chat();

ID:0

На работе у нас есть некое подобие самописной ORM, работающей напрямую с ADO.NET и одна из проблем с которой мы сталкивались при её разработке - это то, что у количества параметров используемых в DbCommand есть лимит, этот лимит накладывается базой данных и у разных баз данных он разный.

Например, у PostgreSQL в каждом SQL statement (под SQL statement имеется в виду то, что в разговорной речи называют SQL запросом) может использоваться не больше 65535 параметров (в одну DbCommand можно отправить множество SQL statement и таким образом в общем DbCommand может содержать больше 65535 параметров).

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

Первым делом я конечно же полез смотреть как эту проблему решает и решает ли вообще Entity Framework...

Написал небольшую заметку о том, можно ли при использовании Entity Framework столкнуться с ограничениями, которые накладывает использование DbCommand под его капотом:⁠ Entity Framework и ограничения DbCommand

Бояринцев .NET

Entity Framework и ограничения DbCommand

На работе у нас есть некое подобие самописной ORM, работающей напрямую с ADO.NET и одна из проблем с которой мы сталкивались при её разработке - это то, что у количества параметров используемых в DbCommand есть лимит, этот лимит накладывается базой данных и у разных баз данных он разный. Например, у PostgreSQL в каждом SQL statement (под SQL statement имеется в виду то, что в разговорной речи называют SQL запросом) может использоваться не больше 65535 параметров (в одну DbCommand можно отправить множество SQL statement и таким образом в общем DbCommand может содержать больше 65535 параметров). В большинстве запросов довольно сложно преодолеть разрешённую планку, мы столкнулись с этим ограничением в двух случаях - в INSERT, когда за один запрос вставляется множество строк: INSERT INTO table_name (column_namе(s)) values (value1, ...), (valueN, ...), ... Если таблица содержит 10 столбцов, то с проблемой мы столкнёмся уже при попытке вставить за один раз 656 строк. И в запросах с использованием оператора IN: SELECT…

Проблемы придумали и костылей нагородили - in - решается через Udt тогда будет 1 параметр , много инсертов - sql bulk copy или тот же udt

источник

10:11пожаловаться #6

ВО

Влад Ого in var chat = new Chat();

ID:0

На работе у нас есть некое подобие самописной ORM, работающей напрямую с ADO.NET и одна из проблем с которой мы сталкивались при её разработке - это то, что у количества параметров используемых в DbCommand есть лимит, этот лимит накладывается базой данных и у разных баз данных он разный.

Например, у PostgreSQL в каждом SQL statement (под SQL statement имеется в виду то, что в разговорной речи называют SQL запросом) может использоваться не больше 65535 параметров (в одну DbCommand можно отправить множество SQL statement и таким образом в общем DbCommand может содержать больше 65535 параметров).

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

Первым делом я конечно же полез смотреть как эту проблему решает и решает ли вообще Entity Framework...

Написал небольшую заметку о том, можно ли при использовании Entity Framework столкнуться с ограничениями, которые накладывает использование DbCommand под его капотом:⁠ Entity Framework и ограничения DbCommand

Бояринцев .NET

Entity Framework и ограничения DbCommand

На работе у нас есть некое подобие самописной ORM, работающей напрямую с ADO.NET и одна из проблем с которой мы сталкивались при её разработке - это то, что у количества параметров используемых в DbCommand есть лимит, этот лимит накладывается базой данных и у разных баз данных он разный. Например, у PostgreSQL в каждом SQL statement (под SQL statement имеется в виду то, что в разговорной речи называют SQL запросом) может использоваться не больше 65535 параметров (в одну DbCommand можно отправить множество SQL statement и таким образом в общем DbCommand может содержать больше 65535 параметров). В большинстве запросов довольно сложно преодолеть разрешённую планку, мы столкнулись с этим ограничением в двух случаях - в INSERT, когда за один запрос вставляется множество строк: INSERT INTO table_name (column_namе(s)) values (value1, ...), (valueN, ...), ... Если таблица содержит 10 столбцов, то с проблемой мы столкнёмся уже при попытке вставить за один раз 656 строк. И в запросах с использованием оператора IN: SELECT…

мы решили вопрос с in с помощью темп таблиц и пересборки запроса прям перед отправкой орм к бд

источник

10:22пожаловаться #7

ВО

Влад Ого in var chat = new Chat();

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

источник

10:24пожаловаться #8

ВО

Влад Ого in var chat = new Chat();

и не стоить его заново

источник

10:24пожаловаться #9

NK

ID:0 in var chat = new Chat();

Про то, чем хорошая отложенная инициализация и как ее реализовать

https://habr.com/en/post/522184/

#lazy

Хабр

Ленивая инициализация в C#

Отложенная инициализация или «ленивая» инициализация — это способ доступа к объекту, скрывающий за собой механизм, позволяющий отложить создание этого объекта до...

источник

11:27пожаловаться #10

AV

Artiy Velk in var chat = new Chat();

всем прет
склоняют к тому чтобы заюзать
service fabric on-premise
посему хотел бы узнать подводные
может кто уже юзает :)

источник

11:31пожаловаться #11

NK

ID:0 in var chat = new Chat();

Our platform helps caregivers to make real-time care while improving care coordination & workflows. This has led us to create the most innovative patient engagement solution on the market. We are looking for a Backend Developer to join our Kyiv team!

https://devdigest.today/vacancy/59

Developers Digest

Backend Developer

Oneview Healthcare is a global company, working with hospitals and senior care facilities around the world.

источник

12:01пожаловаться #12

Я

Ярослав in var chat = new Chat();

Как в Ef Core замапить вьюху?

источник

13:54пожаловаться #13

VL

Vova Lantsov in var chat = new Chat();

Ярослав

Как в Ef Core замапить вьюху?

типо так?

ActionResult MyAction([FromBody] Model m)
{
    DbModel dm = map(m);
    context.Add(dm);
}

источник

13:56пожаловаться #14

Я

Ярослав in var chat = new Chat();

не, есть датаконтекс и в нём нужно замапить вьюху

источник

13:57пожаловаться #15

Я

Ярослав in var chat = new Chat();

источник

13:57пожаловаться #16

Я

Ярослав in var chat = new Chat();

я так понимаю как-то так

источник

13:57пожаловаться #17

Я

Ярослав in var chat = new Chat();

что-то типа

источник

13:57пожаловаться #18

Д

Дима in var chat = new Chat();

ID:0

Про то, чем хорошая отложенная инициализация и как ее реализовать

https://habr.com/en/post/522184/

#lazy

Хабр

Ленивая инициализация в C#

Отложенная инициализация или «ленивая» инициализация — это способ доступа к объекту, скрывающий за собой механизм, позволяющий отложить создание этого объекта до...

Блин

источник

13:58пожаловаться #19

Д

Дима in var chat = new Chat();

А у нас так не принято

источник

13:59пожаловаться #20