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


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

V>На "том конце" выгодней использовать In32 или даже UIn32, в случае которого опять боксинг, согласно приведённого кода.
Непонятное утверждение. Если нам на приёмном конце удобнее иметь Int32, то делаем int a = d.GetInt16().
Если программист намеренно сделал в базе поле int16, но читает его через int a = d.GetInt32(), то он сам себе дебил.

V>>>Ну так из приемного буфера (который уже managed) — в MemoryRecordBuffer, а оттуда в датасет или в поля объектов какого-нить ORM.
S>>Вот не вижу этого момента "из приёмного буфера".
V>Я приводил и сниппеты и ссылки дотнетного ODBC-драйвера, вернись да посмотри.
Дотнетный ODBC драйвер никакого отношения к MemoryRecordBuffer не имеет. С чего вы взяли, что ODBC драйвер как-то применяется при заполнении MemoryRecordBuffer.


V>В которых всё не лучше:
V>https://github.com/mysql/mysql-connector-net/blob/502d718bed8ca9cf81a3a0397574f24ec41b25ba/MySQL.Data/src/datareader.cs#L619
V>

V>   public override Int32 GetInt32(int i)
V>    {
V>      IMySqlValue v = GetFieldValue(i, true);
V>      if (v is MySqlInt32)
V>        return ((MySqlInt32)v).Va

V>      return (Int32)ChangeType(v, i, typeof(Int32));
V>    }
V>

Ну, это же MySQL. Его задача — "чтобы хоть как-то работало".

V>Речь о том, как по-факту.
Ну, вы только что несли чушь про то, что все пользуются ODBC драйвером потому, что не существует OLE DB.
По факту оказалось, что для всех мало-мальски известных СУБД написан менеджед-драйвер.
То, что он неэффективен — заслуга авторов драйвера, а не команды из Редмонда.

V>OLEDB проще, т.к. это некая объектная модель на основе COM.
И?

V>Вот OLEDB именно так и устроен с ценой одного виртуального вызова на одно чтение одного поля.
Точно одного? Вы смотрели в исходники OLE DB драйверов? Снаружи-то и у дотнета один виртуальный вызов на чтение одного поля.

V>Речь о кач-ве этой обертки.
Речь о том, что эта обёртка вообще не нужна.

V>Это локальная база, в основном.
Ну, так как раз для неё и нужно, в основном, выжимать такты.

V>Лень смотреть еще и на Postgre-дрова, но вот для MySQL ссылку привёл — мрак.


V>>>Я говорил как оно есть по-факту, а ты рассуждаешь как оно могло бы быть, если бы все в мире действовали самым разумным способом.
S>>Как видим, все действуют именно так, как я говорю.

V>Ложь.
V>Причём, ложь глупая, игнорующая реальность.
В смысле "ложь"? Вы только что рассказывали, что все пользуются генерик ODBC драйвером, и вынуждены жить с его плохим качеством. По факту, оказалось, что всё ровно так, как я говорил — для основных СУБД существует родной дотнетный драйвер.

V>Нет, не страдает.
Ну конечно же страдает. Как вы думаете, что будет делать OLE DB, если я привяжу поле типа Int16 к буферу типа Int32? Ну, боксинга, наверное, не будет. Но тем не менее, будут преобразования на стороне драйвера, которые потребуют лишних затрат.

V>Страдаешь ты непонимаем той простой вещи, что зачитка данных и вообще задачи драйвера БД — это такие же задачи как сериализации-десериализации.

V>И что если (допустим) кто-то где-то навертел слои абстракций, то и обходить их надо как принято — через IoC.

V>Сравни poll-метод в случае "матрёшки" абстракций:

V>

V>class Layer1Obj {
V>    public virtual int GetInt32(int index) {}
V>}

V>class Layer2Obj {
V>    Layer1Obj _obj1;

V>    public virtual int GetInt32(int index) {
V>        return _obj1.GetInt32(int index);
V>    }
V>}

V>...

V>class Layer10Obj {
V>    Layer9Obj _obj9;

V>    public virtual int GetInt32(int index) {
V>        return _obj9.GetInt32(int index);
V>    }
V>}
V>

V>Сравнить надо с принятым в OLEDB подходом с акцессорами, когда акцессоры устанавливаются на текущий recordset и вызываются одной командой.

V>В дотнете такой подход можно сравнить с подпиской на события:
V>

V>class Layer10Obj {
V>    Layer9Obj _obj9;

V>    public event SomeEventSignature SomeEvent {
V>        add { _obj9 += value; }
V>        remove { _obj9 -= value; }
V>    }
V>}
V>

V>IoC-подход "прошивает" слои абстракции (бо сам OLEDB — уже абстракция).
Очень отдалённая абстракция, т.к. "Аксессор" в OLE DB — это всего лишь описание маппинга в некоторой структуре. Т.е ответственность за преобразования типов тоже лежит на драйвере.
Это перечёркивает любые шансы на то, что обращение к данным превратится в "чтение по смещению" без копирования.


V>Банальную задачу сериализации/десериализации ни сформулировать не могут, ни решить.


V>Как ни крути, но в плане доступа к БД над дотнетом как проклятие висит.
V>Днище.
Ну, коллега — это же золотое дно! Напишите вменяемый драйвер для MySQL, да продайте ораклу за пару сотен тыщ.


S>>Если мы захотим сделать что-то более оптимальное, чем дефолтный драйвер поверх универсального коннектора типа OLE DB или ODBC, то придётся погрузится вот в эти подробности.

V>Ой, уже страшно...
V>Аж протокол распарсить...
V>Неподъёмного веса задача. ))
V>Ты хоть себя слышишь?
Я-то да, а вот у вас явно с усвоением проблемы. Дело не в сложности задачи, а в том, что протокол у каждого свой. И способ получения буфера, и лэйаут в этом буфере, и способы передачи метаданных.
Поэтому никакого особенно общего кода там не будет.


S>>По факту там внутри — массив структур.
V>Опять глупая ложь. ))
Хорошо. Массив указателей на структуры.