Скучаю по процедурам

Скучаю по процедурам

Не скучаю ни разу

Не скучаю ни разу

У меня стокгольмский синдром от универа

что можно сделать что бы в Contains не учитывало регистр?

внутри Parallel.ForEach вылез ексепшен: индекс вне границ массива

как такое может быть?

https://i.gyazo.com/6e3fcaeaded1b46ec2b68a3b048a057c.png

либо я чего то непонимаю

либо я чего то непонимаю

судя по скрину, эксепшен прилетает с 416й строки - вот там и надо смотреть

пытаюсь щас отловить в чем бан, хрен пойми

изредка бывает что в списке нулевые объекты

но не могу понять откуда они там берутся

хоть убей не догоняю

т. е. null что ли?

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

https://i.gyazo.com/9a00887cc5b60c5a6fd027fa90bdfbb4.png

короче они появляются после фильтрации в палалель форич

https://i.gyazo.com/a86db96135e8586cf754dbe22cb320ee.png

на входе лист юзеров, без нулевых объектов

а на выходе с нулевыми, но не всегда а иногда только

хз почему так

наверное потоки не успевают обрабатывать какие то и возвращают null

видимо потому, что users - обычный List < Т >, который не сильно может в многопоточность

ну в 9 из 10 случаем все нормально

случаев*

Так используй concurrent dictionary или bag или еще че-нить

раз у тебя многопоточная обработка - стоит пользоваться соответствующими классами

чтобы не было "моё приложение работает 9 раз из 10"

я думал parallel и есть такой класс)

ну он предоставляет возможность параллельной обработки данных

о потокобезопасности обработки заботиться нужно тебе

так а что можно предпринять в данной ситуации?

чем заменить лись юзер тогда?

лист

как минимум можешь попробовать для листа указать начальную емкость - Capacity - чтобы он при добавлении элементов не пересоздавал внутренний массив

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

https://i.gyazo.com/a86db96135e8586cf754dbe22cb320ee.png

Для записи пользователей в коллекцию внутри параллел форыч используй ConcurrentBag. А когда выйдешь из него делай users.AddRange(concurrentbag)

дддддддддд

кто-нибудь юзал бесплатный сертификат со startsll на IIS?

дддддддддд

Такой презентабельный мужчина в костюме и аниме смотрит. Даже сразу и не подумаешь

Такой презентабельный мужчина в костюме и аниме смотрит. Даже сразу и не подумаешь

А что не так с аниме?)

А что не так с аниме?)

Скользкая дорожка.

Алкоголизм лучше аниме

Хаяо Миядзаки

И никакой скользкой дорожки

аниме под алкоголизм, все норм

Ну гибли это шедевры, х/мф

Но с них все начинается!!

Я вас предупредил........

.......

Я вас предупредил........

А на фотке в профиле это до начала просмотра аниме или после?

Knock knock Race condition Who's there?

с dapper кто нибудь работал? он умеет сам создавать таблицы? не очень хочется вручную sql создания писать... там у объекта полей штук 40

с dapper кто нибудь работал? он умеет сам создавать таблицы? не очень хочется вручную sql создания писать... там у объекта полей штук 40

Конечно не умеет

Конечно не умеет

и что теперь делать?( вручную создавать?

а EF умеет((

Dapper это просто обертка для того, чтобы смапить данные из запроса на объекты. Dapper - Data Mapper

Ты сравнил даппер и еф

печалька

а можно как то автоматически сформировать запрос на создание таблицы?

ERROR: S client not available

Как ты вообще себе представляешь создание таблицы на лету? А что будет, если у тебя добавились поля/удалились? Что будет если тип поменялся

без орм

Как ты вообще себе представляешь создание таблицы на лету? А что будет, если у тебя добавились поля/удалились? Что будет если тип поменялся

миграции же

миграции же

Ну а миграцию как делаешь?

Ну а миграцию как делаешь?

в этом и весь вопрос

У тебя таблица есть?

Готовая

нет пока, есть только объект с полями которые должны соответствовать столбцам таблицы

но полей очень много

поэтому не хочется че то писать запрос в 100 строк

или больше

Так. А зачем тебе даппер?

мне велели его юзать

а еф запретили

увы

=)))) Пиши скрпиты руками. Совсем другой вопрос, зачем в объекте 40 полей

=)

как все печально(

Еф юзаешь для миграцийи созданий/обновлений. Дапер для селектов

Дапер быстр и сам меппит результат на объекты

как все печально(

А ты даппер вообще смотрел?

Там все равно надо sql руками писать

вот читаю https://metanit.com/sharp/articles/mvc/dapper.php

Еф туговат в селектах, но хорошо справляется с инфраструктурой

Тащить EF только для миграций, мне кажется сильно жирно. Не отвалятся руки написать миграцию руками, ведь для даппера код запросов все так же руками надо будет писать. Заодно каждый раз будет возникать вопрос, зачем там 40 полей в объекте? и не хуйню ли я делаю?

там банковская выкладка из 1С приходит... с кучей полей

не я это придумал))

И

Зависит от проекта. Если у вас 40 сущностей, то поддерживать миграции на сиквеле то еще развлечение

Да не 40 сущностей, а полей примитивных типов. И кажется не 40 а чуть меньше. Штук 35 чтоли...

Это я до примера.

У EF миграции хороши, только когда работаешь один-вдвоем. Если вас хотябы 5 человек, миграции в EF то еще развлечение