Здравствуйте, Danchik, Вы писали:

D>Давай так, мы в linq2db тестируем MySqlConnector давно, и это охренительный провайдер. Были косяки, которые они исправили практически мгновенно.

ЧТД, независимое тестирование выявило косяки.
Еще кому-то требуется объяснять мотив моих рассуждений?
Т.е. даже в случае, если бы не выявило косяки?


D>Вся наша куча тестов от него в восторге

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

Опять же, в рамках тестирования linq2db тестируется не сам провадер, а работоспособность ORM- и LINQ-мапперов под него, верно?
Даже не заглядывая в сами тесты в linq2db ставлю на то, что они написаны из предположения заведомой работоспособности драйвера (любого из используемых в матрице тестов), т.е. целевые юниты тестирования не те, о которых сейчас речь.


D>оракловская поделка просто достала https://github.com/linq2db/linq2db/issues/3145

Я в середине нулевых использовал ODBC-драйвер для подключения к MySQL, потому что найденный мною в сети банально не работал.
Всех подробностей не помню, ес-но, но из основного:
— коннекшены вели себя нестабильно — периодически самопроизвольно закрывались, если к серверу было открыто несколько коннешенов одновременно из разных потоков;
— регулярно плевался исключениями по необъяснимым причинам;
— заметно тормозил, иногда резко нагружал CPU на ровном месте.

Сейчас подумалось, что это вероятнее всего это именно тот драйвер, но тогда это не оракловая поделка, а опенсорсная изначально под крылом MySQL AB.
Sun и затем Оракл купили всё это дерьмо уже в нагрузку.
И оба сосредоточены больше на джаве, чем на дотнете, что может объяснять существущее положение вещей.

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

Кстате, посмотрел, в оракловой доке этот сценарий тоже описывается:
https://dev.mysql.com/doc/connector-odbc/en/connector-odbc-examples-programming-net-csharp.html


D>Ты также забываешь что оракловский недоносок не поддерживает асинки от слова вообще.

Я об этом вообще не рассуждал.
Речь была о несоответствии объёма наличествующих тестов степени важности подобных элементов инфраструктуры.

Но ОК, давай посмотрим, что за асинхронщину они навертели.
Сходу нахожу ключевую точку, через которую отправляются все запросы к базе:

    private async ValueTask<int> SendReplyAsyncAwaited(ValueTask<int> task)
    {
        try
        {
            return await task.ConfigureAwait(false);
        }
        catch (Exception ex)
        {
            SetFailed(ex);
            throw;
        }
    }

Они превращают достаточно легковесный GC-free ValueTask, обеспечиваемый вылизанным кодом метода ValueTask<int> Socket.SendAsync(Memory<byte>, ...) в AsyncStateMachineBox, который реализует IValueTaskSource, т.е. подменяет уже имеющийся более-менее "статический" экземпляр IValueTaskSource (тот экземпляр создан однажды и закеширован в Socket) на создаваемый каждый раз ненужный класс-оболочку.

            // AsyncStateMachineBox looks like a small type, but it actually is not because
            // it will have a copy of all the slots from its parent. It will add another hundred(s) bytes
            // per each async method in CoreRT / ProjectN binaries without adding much value. Avoid
            // generating this extra code until a better solution is implemented.
            var box = new AsyncStateMachineBox<TStateMachine>();

Какие-то тошнотики-олигофрены...

Т.е. чуваки продекларировали, что сделают всем хорошо асинхронщину, но сами в асинхронщине не шарят.
Картина маслом, оно же рука-лицо.

А да, следом они превращают ValueTask в Task зачем-то, т.е. дополнительно заворачивают эту обертку еще аж в трехярусную обертку из 5-ти GC-классов (так оборачивается ValueTask в Task: сначала создаётся обертка через вызов ValueTask.Preserve, потом создаётся делегат, ожидающий выполнения preserved ValueTask, это делегат в своём теле управляет созданным новым экземпляром Task через соотв. TaskCompletionSource).

Ладно, всё, задолбали всеми этими примерами нескончаемого нубства, живущего в "популярном донетном коде".
Неважно, в официальном или левом, типа MySqlConnector.
Уже не смешно.

Сцуко, чем глубже в вопрос погружаешься, тем больше косяков режет глаз.

Здравствуйте, Danchik, Вы писали:

D>Давай так, мы в linq2db тестируем MySqlConnector давно, и это охренительный провайдер. Были косяки, которые они исправили практически мгновенно.

ЧТД, независимое тестирование выявило косяки.
Еще кому-то требуется объяснять мотив моих рассуждений?
Т.е. даже в случае, если бы не выявило косяки?


D>Вся наша куча тестов от него в восторге

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

Опять же, в рамках тестирования linq2db тестируется не сам провадер, а работоспособность ORM- и LINQ-мапперов под него, верно?
Даже не заглядывая в сами тесты в linq2db ставлю на то, что они написаны из предположения заведомой работоспособности драйвера (любого из используемых в матрице тестов), т.е. целевые юниты тестирования не те, о которых сейчас речь.


D>оракловская поделка просто достала https://github.com/linq2db/linq2db/issues/3145

Я в середине нулевых использовал ODBC-драйвер для подключения к MySQL, потому что найденный мною в сети банально не работал.
Всех подробностей не помню, ес-но, но из основного:
— коннекшены вели себя нестабильно — периодически самопроизвольно закрывались, если к серверу было открыто несколько коннешенов одновременно из разных потоков;
— регулярно плевался исключениями по необъяснимым причинам;
— заметно тормозил, иногда резко нагружал CPU на ровном месте.

Сейчас подумалось, что это вероятнее всего это именно тот драйвер, но тогда это не оракловая поделка, а опенсорсная изначально под крылом MySQL AB.
Sun и затем Оракл купили всё это дерьмо уже в нагрузку.
И оба сосредоточены больше на джаве, чем на дотнете, что может объяснять существущее положение вещей.

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

Кстате, посмотрел, в оракловой доке этот сценарий тоже описывается:
https://dev.mysql.com/doc/connector-odbc/en/connector-odbc-examples-programming-net-csharp.html


D>Ты также забываешь что оракловский недоносок не поддерживает асинки от слова вообще.

Я об этом вообще не рассуждал.
Речь была о несоответствии объёма наличествующих тестов степени важности подобных элементов инфраструктуры.

Но ОК, давай посмотрим, что за асинхронщину они навертели.
Сходу нахожу ключевую точку, через которую отправляются все запросы к базе:

    private async ValueTask<int> SendReplyAsyncAwaited(ValueTask<int> task)
    {
        try
        {
            return await task.ConfigureAwait(false);
        }
        catch (Exception ex)
        {
            SetFailed(ex);
            throw;
        }
    }

Они превращают достаточно легковесный GC-free ValueTask, обеспечиваемый вылизанным кодом метода ValueTask<int> Socket.SendAsync(Memory<byte>, ...) в AsyncStateMachineBox, который реализует IValueTaskSource, т.е. подменяет уже имеющийся более-менее "статический" экземпляр IValueTaskSource (тот экземпляр создан однажды и закеширован в Socket) на создаваемый каждый раз ненужный класс-оболочку.

            // AsyncStateMachineBox looks like a small type, but it actually is not because
            // it will have a copy of all the slots from its parent. It will add another hundred(s) bytes
            // per each async method in CoreRT / ProjectN binaries without adding much value. Avoid
            // generating this extra code until a better solution is implemented.
            var box = new AsyncStateMachineBox<TStateMachine>();

Какие-то тошнотики-олигофрены...

Т.е. чуваки продекларировали, что сделают всем хорошо асинхронщину, но сами в асинхронщине не шарят.
Картина маслом, оно же рука-лицо.

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

Ладно, всё, задолбали всеми этими примерами нескончаемого нубства, живущего в "популярном донетном коде".
Неважно, в официальном или левом, типа MySqlConnector.
Уже не смешно.

Сцуко, чем глубже в вопрос погружаешься, тем больше косяков режет глаз.