Пользуемся медицинской системой на базе Cache.
При стартапе в прошлом году...
Обычно стартапами называют новые разработки, а не новые внедрения; поинтересуйтесь у поставщика вашей МИС, когда состоялся их стартап. Скорее всего, в вашем случае действовала обычная схема «поставщик решения<->потребитель решения», в рамках которой вы получили СУБД, а не приобрели её отдельно для собственных разработок (которые, к слову, не каждый поставщик будет приветствовать; наша компания здесь, пожалуй, исключение).
P.S. Я сотрудник не InterSystems, а как раз-таки компании-поставщика МИС «qMS» СП.АРМ.
Между прочим, если не задумываться о переносе в сетевую среду, то очередь на $system.Event.Signal() / WaitMsg() работает в разы быстрее очереди на $increment/$sequence. Жаль, что методы класса $system.Event не работают в сети…
Спасибо автору за спокойный неторопливый стиль изложения оригинального и интересного (особенно начиная со второй части) материала. Хотелось бы только видеть законченные примеры не в отрыве от «идеологии», а как-то поскорее, пока она не забылась.
Интересно, но немного непривычно: обычно клиент даёт команду, а сервер её исполняет.
Вопрос: если через RCE удалённо выполняется $$-функция, как вернуть на локальный сервер её возвращаемое значение?
Автору респект: подобные статьи особенно нужны, т.к. документация скупа на эту тему. Большинству из нас пришлось изучать структуру блоков с помощью REPAIR, пусть новичкам будет чуть полегче.
Если вы используете $Increment исключительно для генерации Id, как в примере статьи, то я не знаю причин, чтобы не заменить его на $Sequence (что, конечно же, не значит, что их нет).
Сухой остаток: InterSystems вводит в язык новую фичу и предлагает на неё переходить, не формулируя чётко критерии, когда это возможно.
Немного успокаивает, что, на вскидку, пострадает лишь искусственный код типа вашего последнего примера (не всё ли равно, что было в вершине глобала, если его всё равно кильнули?), но где гарантия, что нет более тонких слачаев? Именно это и настораживает. Одно дело — писание чего-то нового, другое дело — поддержка и развитие сотен тысяч строк существующего кода, ответственность перед коллегами и клиентами, и т.д.
Ведь функция $Increment должна увеличить значение ^a на 1
Равенство id == ^a гарантируется только в момент присваивания, не так ли? Нигде не обещается, что уже в следующую секунду не налетят «100500 процессов» и не увеличат ^a ещё на 100500.
Про локальные переменные упомянул только потому, что вы указали на неспособность работать с ними $seq как на важное отличие от $i. Нет необходимости — да, согласен, но возможность есть, как и во многих других $-функциях, скорее всего, для сохранения полноты языка.
Выделять разброс Id в какое-то отдельное аномальное явление не стоит — это жизнь, т.к. любой программист, использующий
tstart set id=$i(^a),^a(id)=«что-нибудь» tcommit
не должен полагаться на отсутствие дыр в индексации ^a. Что принципиально изменится, если этих дыр станет немного больше?
Вы и сами в заголовке статьи пишете «а вы уже поменяли?». Что понимается под заменой? Могу ли взять и поменять по контексту /$i(^/ на /$seq(^/, если знаю, что никогда не пользуюсь двухаргументной формой $i()?
Если да, то спецификации функций совместимы.
Если нет, объясните, почему.
Спасибо за статью, но мотивы разработчиков для введения новой функции и для меня остались неясны…
Соглашусь с jxcoder, вполне можно было бы добавить в $Increment кэширование, аналогичное $Sequence, не нарушая её спецификации: нигде ведь не сказано, что при параллельно работающих N процессах, обновляющих один глобал (как в вашем примере), значения id должны распределяться приблизительно равномерно. С приращениями > 1 этот кэш также отлично бы справился. «Дырки» в глобале, которые неизбежно будут получаться, тоже не проблема: они могут быть и сейчас при аварийном завершении процессов/откате транзакций. То, что $I() работает и с глобальными, и с локальными переменными, а $Sequence() — нет, и вовсе «гнилая отговорка»: $I() и сейчас по-разному работает в обоих случаях, очевидно, что каждый случай обслуживает отдельная ветка кода.
Это наверное шутка — оценил ))) Имелась в виду функционально оправданная многострочность, а не одно разбитое на несколько строк выражение.
Думаю, спорить дальше не стоит, у каждого свой опыт и свои предпочтения. Мне когда-то приходилось кодить на ассемблере для компов нескольких архитектур, на этом уровне макросы действительно большое подспорье, а в ЯВУ, в большинстве случаев, скорее анахронизм и источник ненужных проблем. Мы читаем не тот код, который выполняется — вот главная из них.
Это уже вопрос философский. Представьте, что целый комплекс программ уже написан «в точках», а тут кто-то продвинутый решит развивать его (без полного переписывания), используя скобки. Какой будет результат? Улучшится читаемость?
К тому же, корпоративный стандарт может предписывать программирование на классическом M (даже в Cache').
При «нормальном» программировании читать INT-код практически никогда не надо. А когда используешь макросы, то таки-да ))) По сути, это и есть наиболее важная причина, по которой я более не являюсь сторонником макросов. Время программиста дороже, чем сэкономленные милли- (или уже микро- ?) секунды на скорости выполнения при замене вызова подпрограммы вызовом макроса.
Пример 3 оперирует со значением, возвращаемым многострочным макросом.
Понятно, что через переменную вернуть можно (нарушая все правила приличия ))). Не увидел в вашем примере конструкций вида: set result=$$$SomeMacro(...)
Как видно, вы не можете представить себе проекта с тоннами унаследованного кода, куда, тем не менее, продолжает добавляться новый функционал )))
Если уж на то пошло, гораздо труднее представить себе ситуацию, когда многострочные макросы привносят что-то полезное, недостижимое при использовании обычных вызовов функций (методов класса), А ограничений и дополнительных затруднений немало. Попробуйте, например, вернуть значение из многострочного макроса (как его может вернуть однострочный макрос-выражение).
Это твои скрытые знания ))) По тексту статьи можно понять, что сначала генерится .MAC, а потом из него .INT. Что неправильно, ибо тот .MAC, который в objectgenerator-е, имеет отношение к генерации кода, а не к его выполнению. В общем случае .MAC не порождается, лишь в частном случае objectgenerator-а. Стоило бы это уточнить, статья ведь рассчитана на начинающих.
Это неверно, пожалуй, уже лет 7, начиная с Caché 2016.1. В актуальных версиях Caché и IRIS кэшируется всё. (Для кого я, впрочем, это пишу?)
В инструкции к Xiaomi английским по белому: влажная уборка - после двух сухих.
P.S. Я сотрудник не InterSystems, а как раз-таки компании-поставщика МИС «qMS» СП.АРМ.
Вопрос: если через RCE удалённо выполняется $$-функция, как вернуть на локальный сервер её возвращаемое значение?
Сухой остаток: InterSystems вводит в язык новую фичу и предлагает на неё переходить, не формулируя чётко критерии, когда это возможно.
Немного успокаивает, что, на вскидку, пострадает лишь искусственный код типа вашего последнего примера (не всё ли равно, что было в вершине глобала, если его всё равно кильнули?), но где гарантия, что нет более тонких слачаев? Именно это и настораживает. Одно дело — писание чего-то нового, другое дело — поддержка и развитие сотен тысяч строк существующего кода, ответственность перед коллегами и клиентами, и т.д.
Про локальные переменные упомянул только потому, что вы указали на неспособность работать с ними $seq как на важное отличие от $i. Нет необходимости — да, согласен, но возможность есть, как и во многих других $-функциях, скорее всего, для сохранения полноты языка.
Выделять разброс Id в какое-то отдельное аномальное явление не стоит — это жизнь, т.к. любой программист, использующий
tstart set id=$i(^a),^a(id)=«что-нибудь» tcommit
не должен полагаться на отсутствие дыр в индексации ^a. Что принципиально изменится, если этих дыр станет немного больше?
Вы и сами в заголовке статьи пишете «а вы уже поменяли?». Что понимается под заменой? Могу ли взять и поменять по контексту /$i(^/ на /$seq(^/, если знаю, что никогда не пользуюсь двухаргументной формой $i()?
Если да, то спецификации функций совместимы.
Если нет, объясните, почему.
Соглашусь с jxcoder, вполне можно было бы добавить в $Increment кэширование, аналогичное $Sequence, не нарушая её спецификации: нигде ведь не сказано, что при параллельно работающих N процессах, обновляющих один глобал (как в вашем примере), значения id должны распределяться приблизительно равномерно. С приращениями > 1 этот кэш также отлично бы справился. «Дырки» в глобале, которые неизбежно будут получаться, тоже не проблема: они могут быть и сейчас при аварийном завершении процессов/откате транзакций. То, что $I() работает и с глобальными, и с локальными переменными, а $Sequence() — нет, и вовсе «гнилая отговорка»: $I() и сейчас по-разному работает в обоих случаях, очевидно, что каждый случай обслуживает отдельная ветка кода.
См. ECP Lock Guarantee.
Думаю, спорить дальше не стоит, у каждого свой опыт и свои предпочтения. Мне когда-то приходилось кодить на ассемблере для компов нескольких архитектур, на этом уровне макросы действительно большое подспорье, а в ЯВУ, в большинстве случаев, скорее анахронизм и источник ненужных проблем. Мы читаем не тот код, который выполняется — вот главная из них.
К тому же, корпоративный стандарт может предписывать программирование на классическом M (даже в Cache').
Понятно, что через переменную вернуть можно (нарушая все правила приличия ))). Не увидел в вашем примере конструкций вида: set result=$$$SomeMacro(...)
Если уж на то пошло, гораздо труднее представить себе ситуацию, когда многострочные макросы привносят что-то полезное, недостижимое при использовании обычных вызовов функций (методов класса), А ограничений и дополнительных затруднений немало. Попробуйте, например, вернуть значение из многострочного макроса (как его может вернуть однострочный макрос-выражение).