Сообщение Re[59]: MS забило на дотнет. Питону - да, сишарпу - нет? от 03.10.2021 1:26
Изменено 03.10.2021 2:16 vdimas
Re[59]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, 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>Ты также забываешь что оракловский недоносок не поддерживает асинки от слова вообще.
Я об этом вообще не рассуждал.
Речь была о несоответствии объёма наличествующих тестов степени важности подобных элементов инфраструктуры.
Но ОК, давай посмотрим, что за асинхронщину они навертели.
Сходу нахожу ключевую точку, через которую отправляются все запросы к базе:
Они превращают достаточно легковесный GC-free ValueTask, обеспечиваемый вылизанным кодом метода ValueTask<int> Socket.SendAsync(Memory<byte>, ...) в AsyncStateMachineBox, который реализует IValueTaskSource, т.е. подменяет уже имеющийся относительно "статический" экземпляр IValueTaskSource (тот экземпляр создан однажды и закеширован в Socket) на создаваемый каждый раз ненужный класс-оболочку.
Какие-то тошнотики-олигофрены...
Т.е. чуваки продекларировали, что сделаютвсем хорошо асинхронщину, но сами в асинхронщине не шарят.
Картина маслом, оно же рука-лицо.
Ладно, всё, задолбали всеми этими примерами нескончаемого нубства, живущего в "популярном донетном коде".
Неважно, в официальном или левом, типа MySqlConnector.
Уже не смешно.
Сцуко, чем глубже в вопрос погружаешься, тем больше косяков режет глаз.
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>();
Какие-то тошнотики-олигофрены...
Т.е. чуваки продекларировали, что сделают
Картина маслом, оно же рука-лицо.
Ладно, всё, задолбали всеми этими примерами нескончаемого нубства, живущего в "популярном донетном коде".
Неважно, в официальном или левом, типа MySqlConnector.
Уже не смешно.
Сцуко, чем глубже в вопрос погружаешься, тем больше косяков режет глаз.
Re[59]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, 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>Ты также забываешь что оракловский недоносок не поддерживает асинки от слова вообще.
Я об этом вообще не рассуждал.
Речь была о несоответствии объёма наличествующих тестов степени важности подобных элементов инфраструктуры.
Но ОК, давай посмотрим, что за асинхронщину они навертели.
Сходу нахожу ключевую точку, через которую отправляются все запросы к базе:
Они превращают достаточно легковесный GC-free ValueTask, обеспечиваемый вылизанным кодом метода ValueTask<int> Socket.SendAsync(Memory<byte>, ...) в AsyncStateMachineBox, который реализует IValueTaskSource, т.е. подменяет уже имеющийся более-менее "статический" экземпляр IValueTaskSource (тот экземпляр создан однажды и закеширован в Socket) на создаваемый каждый раз ненужный класс-оболочку.
Какие-то тошнотики-олигофрены...
Т.е. чуваки продекларировали, что сделаютвсем хорошо асинхронщину, но сами в асинхронщине не шарят.
Картина маслом, оно же рука-лицо.
Ладно, всё, задолбали всеми этими примерами нескончаемого нубства, живущего в "популярном донетном коде".
Неважно, в официальном или левом, типа MySqlConnector.
Уже не смешно.
Сцуко, чем глубже в вопрос погружаешься, тем больше косяков режет глаз.
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>();
Какие-то тошнотики-олигофрены...
Т.е. чуваки продекларировали, что сделают
Картина маслом, оно же рука-лицо.
Ладно, всё, задолбали всеми этими примерами нескончаемого нубства, живущего в "популярном донетном коде".
Неважно, в официальном или левом, типа MySqlConnector.
Уже не смешно.
Сцуко, чем глубже в вопрос погружаешься, тем больше косяков режет глаз.