Здравствуйте, Sinclair, Вы писали:
S>Выведет причину того, что комбинировать делегаты, возвращающие значение, не имеет смысла.
Угу.
Это расплата за отсутствие генериков в первом дотнете.
Понятно же, что мультикастность можно прикрутить сбоку, но в отсутствии генериков предоставить вменяемую библиотечную реализацию невозможно.
Я над этим вопросом и сам голову ломал в те же года, когда дотнет вышел — раздражает же что любой юзвеский делегат наследуется от мультикаст-делегата.
А по-другому в отсутствии инструментов для типизированного своего оборачивания такой функциональности не сделаешь, поэтому оборачивает система.
И поэтому делегаты такие дорогие в создании и вызове.
V>>Т.е., юридической основы для иска не было. S>Ну, я не хочу сейчас лезть в юридические дебри.
Да нет там никаких юридических дебрей, вот в чём странность.
Т.е. иск юридически ничтожен.
Поэтому, в кач-ве аргументов были не юридические доводы, а "общечеловеческие", филосовские и прочий такой бред.
Это почему суды присяжных, таки, фуфел, судопроизводством должны заниматься профессионалы.
Смотри, вот ты однажды утром проснулся, взял, допустим, открытый стандарт С++, который не покрыт ни патентами, ни запретами на клонирование, ни чем бы то ни было еще.
Вот ты "форкнул" стандарт для себя, добавил нужных тебе фич, назвал С+++, написал компилятор, показал людям.
Ни один юрист не объяснит, с какой радости тебя за это вдруг потащат в суд.
Поэтому, ничего юридического в той истории нет.
Есть изнанка капитализма: деньги (в т.ч. интересы инвесторов и прочее) превыше закона.
S>Возможно, мы сейчас бы жили в мире, где дотнета нет, зато есть java с value-типами и нормальными генериками, а не этой порнографией.
Не факт, достаточно посмотреть на веб.
MS вставляли палки в колеса в течении 15 лет, не давали развивать веб.
Почему? — потому что сами отставали.
MS на веб забила в итоге, бо и так IE в течении 15 лет был лучше любых альтернатив.
А потом эти отстающие с грехом пополам допилили эппловский WebKit до более-менее вменяемого состояния, выкатили Хром.
Сказали: "Вот теперь мы тоже готовы развивать веб, так давайте же его развивать!"
Но 15 лет потеряно.
Так же было бы и с джавой — это были бы такие же точно гири на ногах.
Т.е., в IT индустрии в плане стандартов происходит равнение на отстающих.
А вылезающих вперёд враждебное к друг другу до этого стадо объединившись совместно мочит выскочку, прямо как в старом советском мультике: https://www.youtube.com/watch?v=phl_hFPBY0U
S>То есть вместо двух управляемых платформ мы бы имели одну, сочетающую лучшие стороны обеих.
Имели бы одну платформу, отстающую в развитии от имеющихся сегодня лет на 15. ))
А так дотнет мог делать что хотел...
Ну и Джава ойкнула от неожиданости и тоже начала шевелиться.
S>Ну вот в нашей компании ресурсы, конечно, перекидываются по велению руководства, но продакт менеджмент стоит достаточно близко к руководству, чтобы а) понимать, на основании чего перекидываются ресурсы и б) в определённой степени влиять на приоритеты.
У нас это одни и те же люди.
S>То есть анонимную локальную функцию — можно, безо всяких ворнингов, а именованную — уже нельзя.
На новый круг заход? ))
Вычислительное выражение C# чисто, но блок кода — не факт.
Поэтому блоки нельзя.
S>То есть в делегате ссылаться на потенциально нечистую функцию — ок
Отродясь.
S>а в expression — уже зашквар?
Я так думаю, что из тех соображений, мол, а как нечистую ф-ию переводить в SQL?
Но ограничение всё-равно странное, бо использованный в чистой ф-ии делегат тоже в SQL не уедет, т.е. expression-to-DB провайдер ругнётся в рантайме.
Т.е., можно было бы во всех случаях выбрасывать рантайм-ошибки, в т.ч. и для выражений-блоков, если нет возможности перевести их в SQL.
V>>А как обеспечить чистоту функций на уровне языка — непонятно. S>Это опять рационализация иррационального.
ИМХО, это еще один инструмент проектирования.
Есть же языки, которые позволяют помечать нужные ф-ии как чистые.
В таких ф-иях нельзя производить нечистые вычисления, компилятор не скомпилит.
Причём, это удобней чистых ФП-языков, т.к. ф-ия запросто может быть чистой даже если использует мутабельные переменные в своём теле.
V>>Про локальные я полностью согласен — это непредсказуемая дичь в случае Expression и обычных делегатов, т.к. не всегда очевидно, что именно захватывается и где, т.к. таких локальных ф-ий может быть несколько, но они шарят общий контекст. S>Как видим, в случае делегатов это никому не мешает.
Откуда "мы" это видим, если у тебя проявляется та же ошибка, только теперь без ворнинга? ))
Чтобы исправить ошибку, необходимо создать еще одну ф-ию, замыкающую каждый раз новый экземпляр контекста:
var funcs = new List<Func<int>>();
for(int i = 0; i < 4; i++)
{
static Func<int> getI(int i) => () => i; // вспомогательная ф-ия для нового контекста
funcs.Add(getI(i));
}
funcs.ForEach(f => Console.WriteLine(f()));
Используется тот трюк, что в мутабельных языках создаётся новый контекст на каждую ф-ию с замыканием, т.е. аргументы ф-ии показанным образом можно замкнуть byval, в отличие от локальных переменных того же самого контекста, которые замыкаются byref.
Это ж стандартная головная боль JS — регулярная необходимость преобразования захвата переменных byref в byval.
Забавно порой почитывать JS-программистов, которые даже спустя десяток лет опыта в JS в этом плавают.
C# тоже этой головной болью теперь наградили, но хоть компилятор ворнинги выдаёт, если прошляпишь.
А в JS "можно всё" (С).
Но удобней, конечно, когда в языке есть способ явно указать способ захвата переменной — по ссылке или по значению.
Например, как в С++ или PHP.
V>>Но статические локальные ф-ии чисты относительно контекста, т.е. не подменяют значений и ссылок локальных переменных. S>Правильный ответ — локальные функции настолько редко используются в делегатах и выражениях, что всем просто наплевать.
А откуда ты взял про "редко", не поделишься источником статистики? ))
Это просто новая фича, а чуть не весь используемый сейчас в дотнете код был написан до её появления.
А взять наши внутренние либы, писанные специально для .Net Core — это относительно новый код (в среднем пару лет ему), и там все новые фичи используются в полный рост.
И по-факту никакого "редко".
Меня раньше останавливала "тяжесть" локальных ф-ий, если де-факто контекст метода не использовался, но с вводом статических локальных ф-ий последний раздражающий фактор был преодолён.
Я же говорю — в последние годы разработчики дотнета как мои мысли читают, бгг...
Т.е. я хорошо понимаю рассуждения, приводящие к таким решениям, бо именно эти рассуждения происходят у меня при написании кода и каждый раз испытываешь досаду от нехватки тех или иных вещей — и тут ровно эти вещи, вызывающие досаду, исправляются. Ну так сразу понятно, какого склада ума люди за дотнет взялись.
А ты такой пишешь "никому не надо". ))
Как не вспомнить классику: "Слишком далеки они от народа!" (С) А.И.Герцен.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Наследование — далеко не единственный способ сделать это. Есть, к примеру, паттерн Стратегия.
Кстате, хороший пример.
Иногда наследники просто инициализируют базовый класс нужными стратегиями в конструкторе или переопределяют фабричные методы (можно рассматривать как создание стратегий по мере необходимости).
В системе без наследования вместо new пришлось бы использовать паттерны factory или builder, получать "синтаксический оверхед".
Re[74]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, Serginio1, Вы писали:
S> Угу а кто тебе запрещает использовать и интерфейсы и наследование одновременно? S>Зачем в интерфейсы ввели возможность реализации?
Но эта возможность ограничена — в реализации методов участвуют только статические (глобальные) переменные или методы самого интерфейса.
С некоторой натяжкой такую функциональность можно считать чем-то вроде вычислимых столбцов в таблице БД.
Re[75]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>>Нет там такого. I>>Это смотря как смотреть НС>О да, умеючи между строк столько всего можно прочесть.
Имелась ввиду та найденная неплохая практика, что функциональность объекта, которую можно достичь с использованием только его публичной функциональности, стоит выносить за пределы объекта.
В дотнете этот вопрос решили методами-расширениями.
Здравствуйте, vdimas, Вы писали:
V>В системе без наследования вместо new пришлось бы использовать паттерны factory или builder, получать "синтаксический оверхед".
Это если язык не содержит сахара для этого.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[75]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Serginio1, Вы писали:
S>> Угу а кто тебе запрещает использовать и интерфейсы и наследование одновременно? S>>Зачем в интерфейсы ввели возможность реализации?
V>Но эта возможность ограничена — в реализации методов участвуют только статические (глобальные) переменные или методы самого интерфейса.
V>С некоторой натяжкой такую функциональность можно считать чем-то вроде вычислимых столбцов в таблице БД.
Ну учитывая свойства и методы, это мало чем отличается от абстрактного класса.
Суть то в том, что бы как можно меньше писать или копировать код, если он един для всех. Да внутри методов своя реализация но общую часто можно вынести в общий код.
и солнце б утром не вставало, когда бы не было меня
Re[76]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, Serginio1, Вы писали:
V>>С некоторой натяжкой такую функциональность можно считать чем-то вроде вычислимых столбцов в таблице БД. S>Ну учитывая свойства и методы S>это мало чем отличается от абстрактного класса.
Абстрактный класс содержит данные, а дефолтная реализация может содержать только алгоритмы.
Re[86]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, Sinclair, Вы писали:
S>Ну, это была так, схема. С учётом того, что от этой коллекции требуется только добавление, удаление по значению, и прямой перебор, то хватит банального односвязного списка. S>И все операции будут не только lock-free, но и wait-free.
Wait-free будет по чтению, а для вставки в односвязный список wait-free не получится, но оно обычно и не требуется.
Re[77]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Serginio1, Вы писали:
V>>>С некоторой натяжкой такую функциональность можно считать чем-то вроде вычислимых столбцов в таблице БД. S>>Ну учитывая свойства и методы S>>это мало чем отличается от абстрактного класса.
V>Абстрактный класс содержит данные, а дефолтная реализация может содержать только алгоритмы.
Абстрактный класс может содержать данные, а может и не содержать.
Но вот раньше не было такого функционала и плодили классы, там где можно было обойтись свойствами и методами интерфейса. Сейчас когда в интерфейсы ввели возможность реализации
надобность в таких классах отпала.
Например Stream всего два поля
Здравствуйте, Serginio1, Вы писали:
V>>Абстрактный класс содержит данные, а дефолтная реализация может содержать только алгоритмы. S>Абстрактный класс может содержать данные, а может и не содержать.
Не-абстрактный класс тоже может не содержать данные и что?
S>Но вот раньше не было такого функционала и плодили классы, там где можно было обойтись свойствами и методами интерфейса.
Ес-но.
И в присутствии множественного наследования эта новая функциональность интерфейсов была бы не нужна.
S>Сейчас когда в интерфейсы ввели возможность реализации S>надобность в таких классах отпала.
Это малость упрощённый взгляд на вещи.
Рассматривай любую фичу языка в первую очередь как инструмент проектирования.
Например, сейчас на интерфейсах можно расписывать стратегии, а затем из многих их собирать требуемую.
До этого подход сбора стратегий простой комбинаторикой не работал — требовалось делегирование вызовов методов, копипаста и т.д.
Сейчас такой код станет в разы чище.
Здравствуйте, Serginio1, Вы писали:
S>>>Файловые базы всегда были быстрее ибо все происходит в одном процессе. НС>>Или не потому. S>А за счет чего?
1. Запись на файл быстрее за счёт асинхронности.
Записывая данные в файл, твоя программа обычно не ожидает завершения фактической записи на диск.
Попробуй на каждый чих делать что-то типа Flush() и прочувствуй разницу.
2. Чтение из файла быстрее за счёт кеширования.
При повторном чтении того же файла ты будешь с большой вероятностью читать данные не с диска, а из RAM.
Но GUI приложению доступны те же технологии, просто ими надо озаботиться самостоятельно.
Я когда-то еще в конце 90-х баловался с асинронщиной и кешированием — только это и позволяло вменяемо работать в случае, когда сервер приложений на другой машине, т.е. в трехзвенке.
При том что основной парк тогдашних клиентских машин — от пней-2 233-333 до селерона-3 700 (уже в 2000-м).
S>Интерпретатор выигрывает!
Интерпретатор — он для юзверского кода.
Но на системном уровне можно было сделать и асинхронщину, и локальное кеширование с синхронизацией.
В т.ч. локальное кеширование в локальной БД (я кешировал в локальной БД MS Access).
Например, при вводе справочных данных клиент не ожидал ответного суррогатного auto-number ключа, т.к. клиент еще в начале работы резервирует себе уникальный список ключей, т.е. всегда при вставке знает суррогатный ключ справочной записи, поэтому ему не требуется синхронно ожидать ответ для продолжения работы.
Re[84]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Serginio1, Вы писали:
S>>>>Файловые базы всегда были быстрее ибо все происходит в одном процессе. НС>>>Или не потому. S>>А за счет чего?
V>1. Запись на файл быстрее за счёт асинхронности. V>Записывая данные в файл, твоя программа обычно не ожидает завершения фактической записи на диск. V>Попробуй на каждый чих делать что-то типа Flush() и прочувствуй разницу.
Ну для Dbase там при записи Flush то и используется. Для SQL там различные варианты. Но транзакции кстати ускоряют запись.
V>2. Чтение из файла быстрее за счёт кеширования. V>При повторном чтении того же файла ты будешь с большой вероятностью читать данные не с диска, а из RAM.
Ну тоже само и для SQL
S>>Интерпретатор выигрывает!
V>Интерпретатор — он для юзверского кода. V>Но на системном уровне можно было сделать и асинхронщину, и локальное кеширование с синхронизацией. V>В т.ч. локальное кеширование в локальной БД (я кешировал в локальной БД MS Access).
V>Например, при вводе справочных данных клиент не ожидал ответного суррогатного auto-number ключа, т.к. клиент еще в начале работы резервирует себе уникальный список ключей, т.е. всегда при вставке знает суррогатный ключ справочной записи, поэтому ему не требуется синхронно ожидать ответ для продолжения работы.
Так файловые базы это чисто юзверский код. А что касается ключей то и в 1С есть стратегии
Но GUID у них тоже своеобразный. Он формируется из нормального гуида но в нем есть дата и автоинкремент. https://infostart.ru/1c/articles/635159/
Здесь уже обсуждали UUIDv6
есть GUID'ы, которые используют текущее время в качестве префикса. http://gh.peabody.io/uuidv6/
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> Ну для Dbase там при записи Flush то и используется.
Откуда дровишки?
Эта функциональность появилась только в WinXp API, но, судя по локали русского языка, 1С не использует виндовые дрова к dbase, там какая-то библиотечная реализация из 90-х или даже конца 80-х.
S>Для SQL там различные варианты. Но транзакции кстати ускоряют запись.
Для удаленного сервера с пингом 50 ms кол-во итераций связи критично, есно.
>2. Чтение из файла быстрее за счёт кеширования. V>>При повторном чтении того же файла ты будешь с большой вероятностью читать данные не с диска, а из RAM. S> Ну тоже само и для SQL
Нет в 1С локального кеширования, будет просить удаленный сервак на каждый чих.
Отсюда видимые тормоза при открытии форм.
Здравствуйте, Ночной Смотрящий, Вы писали:
V>>В системе без наследования вместо new пришлось бы использовать паттерны factory или builder, получать "синтаксический оверхед".
НС>Это если язык не содержит сахара для этого.
Хоть обсахарись. Если ты построил вавилонскую башню, даже без капельки наследования, это все равно хрупкий код. Что нибудь внизу сломал, и вместе с этим ломается все остальное.
Тут даже простая цепочка функций обладает ровно тем же свойством. Изменил свойства стартовой функции в цепочках — будь добр найти все цепочки, которые зависят прямо или косвенно, и пофикси.
Собственн это особенность этой самой вавилонской башни, а вовсе не метода, каким её можно строить.
Более того — наследование интерфейсов обладает ровно тем же недостатком, просто потому что интерфейс предполагает реализацию и определенную семантику.
Re[86]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, vdimas, Вы писали: V>Нет в 1С локального кеширования, будет просить удаленный сервак на каждый чих. V>Отсюда видимые тормоза при открытии форм.
На самом деле есть. Во всяком случае на сервере приложений полученные данные кэшируются
Обычный кеш
Если при обращении к обычному кешу требуемых данных в нем нет, то выполняется чтение данных объекта из базы данных и сохранение их в кеше. Уникальным идентификатором для кеша в данном случае будет являться ссылка на объект базы данных. Поэтому данные каждого считанного объекта могут существовать в кеше в одном из двух видов: либо все данные объекта, либо представление объекта.
Таким образом, если мы обратимся к кешу для получения представления объекта и в кеше есть информация для нашей ссылки, данные будут взяты из кеша (если в кеше весь объект, нужное представление будет получено из данных объекта).
Если в кеше нет информации для нашей ссылки, из базы данных в кеш будут считаны только поля, необходимые для формирования представления объекта.
Если мы обратимся к кешу для получения реквизита объекта и в кеше есть информация для нашей ссылки, дальнейшие действия будут зависеть от того, что находится в кеше.
Если в кеше весь объект, значение реквизита будет получено из кеша. Если в кеше представление объекта, оно будет удалено из кеша, и в кеш будут считаны все данные объекта. Если же при получении реквизита объекта в кеше нет информации для нашей ссылки, из базы данных будут считаны все поля объекта.
Считанные данные будут находиться в кеше до тех пор, пока не наступит одно из следующих событий:
считанные данные будут вытеснены из кеша другими считанными данными других объектов (переполнение кеша);
при очередном обращении к кешу окажется, что считанные данные были изменены в базе данных;
закончится интервал времени в 20 минут.
Все считанные данные помещаются в последовательную очередь, и, поскольку объем кеша ограничен, наиболее старые данные будут вытесняться из кеша последними считанными.
При повторном обращении к кешу за данными уже считанного объекта будет анализироваться интервал времени, прошедший с момента появления данных в кеше.
Если обращение происходит в пределах 20 секунд после поступления данных в кеш, данные считаются верными (валидными). Если интервал превысил 20 секунд, будет выполняться проверка на соответствие версии данных, хранящихся в кеше, версии данных, находящихся в базе данных.
Если окажется, что версии данных не совпадают (т. е. произошло изменение данных в базе данных), данные, находящиеся в кеше, будут удалены из него, и будет выполнено повторное считывание данных из базы данных. Начиная с этого момента, идет отсчет следующего 20-секундного интервала валидности этих данных.
Кроме всех вышеперечисленных событий считанные данные будут удалены из кеша по истечении 20 минут после их последнего считывания из базы данных.
Таким образом, при последовательном выполнении двух операторов (листинг 14.43), где Номенклатура – это ссылка на объект справочника, на выполнение второго оператора будет тратиться гораздо меньше времени, поскольку в первом случае будет выполняться обращение к базе данных, а во втором – чтение из оперативной памяти (кеша объектов).
Транзакционный кеш
Если обращение к данным происходит в рамках транзакции, то оно переадресуется транзакционному кешу. В рамках транзакции в «1С:Предприятии» выполняются все операции, приводящие к изменению данных в базе данных. Например, в рамках транзакции выполняется обработка проведения документа.
Транзакция – это неделимая последовательность манипулирования данными, переводящая базу данных из одного целостного состояния в другое. Если по каким-то причинам одно из действий транзакции невыполнимо, база данных возвращается в то состояние, которое было до начала транзакции (происходит откат транзакции – Rollback).
Транзакционный кеш по сути представляет собой ту же последовательную очередь, что и обычный кеш. Разница заключается в том, что все данные, находящиеся в транзакционном кеше, являются валидными (гарантированно актуальными).
При считывании данных в транзакционный кеш устанавливается блокировка на данные в базе данных, поэтому они гарантированно не могут быть изменены до окончания транзакции.
Транзакционный кеш хранит считанные данные до тех пор, пока они не будут вытеснены более поздними или пока не закончится транзакция. По окончании транзакции кеш очищается, однако действия, выполняемые при этом, зависят от состояния завершения транзакции.
Если транзакция завершена успешно (Commit), данные всех объектов, содержащиеся в транзакционном кеше, переносятся в обычный кеш, а транзакционный кеш очищается (рис. 14.34).
Рис. 14.34. Транзакция завершена успешно
Если был выполнен отказ от изменений (Rollback), то просто очищается транзакционный кеш (рис. 14.35).
и солнце б утром не вставало, когда бы не было меня
Re[57]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, Ikemefula, Вы писали:
V>>Статья от 2018-го. I>С разморозкой — нынче сентябрь 2021. I>Ты бы роадмап глянул? 2018й это выход 3.0. На сегодня актуальна 4.4
Это всё копейки и на суть обсуждаемого в той статье не влияет.
Особенно "более лучший вывод типов" и "туплы-генерики".
Re[57]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, Sinclair, Вы писали:
V>>Я просил ссылку на тот код чтобы понять, наконец, это реальный код или умозрительный твой. S>Это был умозрительный мой код.
Эдак тебя колбасит от чудовищной наглости до чудовищной же скромности. ))
Пять раз пришлось спрашивать...
S>Неожиданно оказалось, что драйвер с эквивалентным кодом таки существует.
Чё-та в голос уже...
Несерьёзный ты человек, однако.
Но за юмор спасибо.
V>>И так там вдоль всего кода. V>>И тоже боксинг в простейших случаях: S>Это не "простейшие" случаи; это смена типа поля при чтении. Надо полагать — не самый частый случай.
У кого как.
В дотнете типы short/ushort, sbyte/byte неудобны для оперирования, бо весь АПИ расписан на знаковом int, но в БД эти типы удобны и популярны для суррогатных ключей заведомо небольших справочных данных.
Здравствуйте, Sinclair, Вы писали:
V>>Даже не знаю, что на это фейеричное ответить... S>Ну, можно ответить "ой, я невнимательный, спасибо, что указали мне на мою ошибку".
Разница в том, что я говорю как в дотнете обстоят дела де-факто, а ты даёшь что-то свежеиспечённое от двух неких чуваков: https://github.com/bgrainger https://github.com/caleblloyd
на коленке с 0-ля написавших альтернативу официальному драйверу от Оракла.
Теперь берём некий боевой новый проект и вот мелькнула мысль взять с гитхаба код этих двух чуваков...
Ничего против этой парочки не имею, конечно... но ты примерно представляешь объем тестов корректности, которые потребуется написать, чтобы принять решение — стоит рисковать брать самописный левый драйвер в боевую разработку или нет?
Представь, что решения принимаешь ты и отвечаешь за них тоже ты, в т.ч. возможным банкротством.
Я так думаю, что ты никаких тестов писать не будешь, тихонько возьмёшь официальный драйвер, как это делают 99.99% разработчиков и забъёшь на разницу в эффективности болт.
Зато здесь ля-ля-ля разводить так удобно, потому что безопасно...
Вот так мы и спорим — я о реальном положении дел, а ты об умозрительном, о том, как бы тебе хотелось. ))
Re[87]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, Serginio1, Вы писали:
V>>Нет в 1С локального кеширования, будет просить удаленный сервак на каждый чих. V>>Отсюда видимые тормоза при открытии форм. S>На самом деле есть. Во всяком случае на сервере приложений полученные данные кэшируются
Наверно разница в том, что сервер приложений (это для веба?) один для всех подключённых клиентов, т.е. про актуальность кеша можно делать хоть какие-то предположения.
Другое дело когда каждый клиент независимо коннектится к SQL-серваку как оно есть в традиционном использовании 1С в связке с MS SQL.
Тогда в отсутствии специального механизма поддержки актуальности кеша попытка кешировать данные вредна.
А такого механизма заведомо нет, я смотрел схемы таблиц, которые создаёт на серваке 1С — в таблицах нет служебного поля для целей поддержки когерентности клиентских кешей.
Сама схема обычно проста:
— в целевую таблицу/таблицы, описывающие некую сущность, вводится служебное поле — токен синхронизации, целое число некоей ширины;
— для данной сущности при каждом её изменении этот токен инкрементируется, при переполнении токена он сбрасывается у всех записей таблицы;
(например, текущий токен был равен 42, обновили в одной транзакции несколько строк в таблице, у обновлённых строк токен стал 43)
— клиенту возвращается некий ответ на прикладной запрос, в котором рядом с внешним ключом идёт токен синхронизации сущности, на которую ссылается внешний ключ.
— при обнаружении превышения значения токена синхронизации, клиент запрашивает требуемые сущности (или "точечно" для участвующих в запросе, или последние обновления для всего справочника через простое условие select * from SomeEnity where SyncToken > @ClientToken); клиент обновляет свой кеш справочника, вычленяя max(SyncToken) по ходу обновления, это и будет текущий его токен синхронизации.
Что в этой схеме хорошо — это отсутствие трафика зеркалирования данных.
Например, пришёл новый товар, заводятся куча новых карточек, но товар еще на склад не поступил.
И пока эти карточки заводятся и многократно редактируются — будет изменяться их токен синхронизации.
Но т.к. новые карточки еще нигде на операторских местах продавцов не фигурируют — ПО продавцов эти ненужные им обновляемые справочные данные и не запрашивает.
Назавтра продавцы включили свои терминалы, зачитали ненулевые регистры товаров на складе, зачитали соотв. справочники — и огонь торговать.
S>Считанные данные будут находиться в кеше до тех пор, пока не наступит одно из следующих событий: S>считанные данные будут вытеснены из кеша другими считанными данными других объектов (переполнение кеша); S>при очередном обращении к кешу окажется, что считанные данные были изменены в базе данных; S>закончится интервал времени в 20 минут. S>Все считанные данные помещаются в последовательную очередь, и, поскольку объем кеша ограничен, наиболее старые данные будут вытесняться из кеша последними считанными.
Насколько я понял из описания, у них один кеш на все сущности, а сам кеш не является точным-актуальным, т.к. реализован через набор допущений.
Объективно если — это неуд.
(если к базе можно подключаться мимо сервера приложений)
S>Если обращение к данным происходит в рамках транзакции, то оно переадресуется транзакционному кешу. В рамках транзакции в «1С:Предприятии» выполняются все операции, приводящие к изменению данных в базе данных. Например, в рамках транзакции выполняется обработка проведения документа.
Ну...
У меня код проводки документа жил на стороне БД, ес-но.
Поэтому и работал раз в 100 быстрее.
(если не больше)
На клиенте таблица непроведенных документов, можно просто мышкой нажать на строку и провести вниз-вверх (с прокруткой) не отпуская, выделяя сколько требуется, потом нажать "Провести" и куча складских документов мгновенно проводилась. Это недостижимые для 1С космические технологии. ))