hi all.

Возможно ли вместо вот этого:
- сделать вот такой сахар:


ЗЫ. И еще вопрос, давно мечтал спросить, да всё как-то стеснялся. Возможно ли создание пространства имён, общего для всех коннектов ? То есть, пишем/читаем туда ВСЕ ВМЕСТЕ, кто первый записал - того и тапки.

ЗЗЫ. Сильно не бить! :-)

kdvя не очень понял, чем отличается $ от $$. переменная сессии - $, переменная транзакции - $$ ? Да, именно так.

kdvИ, насчет
$ctx001 = cast(rand()*1000 as int);
то есть, как упоминание переменной, сильно сомневаюсь , особенно потому, что время жизни этих переменных не больше времени жизни коннекта. Были бы они персистентными - тогда еще туда сюда (по аналогии со столбцами таблиц).сомнение - в чём ? время жизни переменных и упрощение синтаксиса - вроде бы не пересекающиеся понятия ?..

dimitrкак по мне - данунах.ну, значит и Кальтенбруннеру будет тоже самое, если не сильнее.
Амэн. :-)

Симонов Денисв принципе с пакетами можно сделать что-то типаНе вижу в этом коде "революционной новизны", позволяющей всем коннектам видеть/менять одну и ту же контекстную переменную. Это же просто две функции-обёртки, позволяющие каждому коннекту манипулировать СВОИМ СОБСТВЕННЫМ "инстансом" этой самой MyVar, нет ?

Симонов ДенисТаблоидпозволяющей всем коннектам видеть/менять одну и ту же контекстную переменнуюнафига это надо? В прицепе можно вывернуться и сохранять и считывать значения из постоянной таблицы, естественно поимев ряд недостатков.Держать в одном shared-списке инфу, существование которой без подключений к базе невозможно. Как пример - вопрос вида "кто сейчас подключен к базе и чё они там делают ?", задаваемый НЕ админом, а каким-нибудь там руководителем, кадровиком, СБшником и проч.

Юзать mon$attachments годится только для случая, когда юзера различимы на уровне базы. Для случая, когда они прописаны в какой-нить справочной таблице и все лезут под одним именем - не катит. К тому же, все коннекты видны только sysdba или владельцу.
Юзать mon$statements - лишняя нагрузка на ФБ. Содержимое mon$sql_text всё равно никто из юзеров не поймёт. Видимость чужих активностей - также как для mon$att.

Толкать сведения по юзерам и их деятельности в приложении в fixed-таблицу - не айс. Лишние телодвижения ФБ при обращении даже к rdb$database широко известны в узких кругах. Да и мусор там будет копиться.

DarkMasterIn-memory для классика не прокатитCS, тем не менее, использует shared-область памяти для разруливания блокировок. Значит, когда надо - прокатывает... ;-)

kdvпиши свой препроцессор.Чё ?! Хорош издевацца-то...

Симонов ДенисТаблоидЮзать mon$statements - лишняя нагрузка на ФБ. Содержимое mon$sql_text всё равно никто из юзеров не поймёт. Видимость чужих активностей - также как для mon$att.Кроме админа никому не нужно. Да и тому редко требуется.Нужен не сам sql-текст деяний, а "кто в какой режим приложения вошёл". Этим интересуются, когда хотят кого-то отследить, что-то предотвратить, короче - когда начинаются всякие шпионские игры.
Ясен пень, что mon$-таблицы тут вообще рядом не лежат. Никак.

Симонов Денисну в общем-то как я понял у Таблоида к rdb$database именно эта претензия. Или я не въехал в суть?Хотелось бы иметь таблицу:
1) хранимую всегда только в памяти сервера;
2) организованную как Map (точнее: TreeMap, чтобы можно было обходить её в порядке возрастания ключей);
3) внетранзакционную (иначе опять версии, мусор и проч);
4) содержимое которой было бы видно всем коннектам и могло бы ими меняться.

Симонов Дениспогоди. Иметь таблицу в памяти с кучей записей это одно. Совсем другое иметь возможность получения констант без обращения к таблицам."ТАБЛИЦЕЙ" я назвал эту структуру просто по инерции. Это должно быть то, что в java называется TreeMap'ом - структурой, реализующей междуморд Map, и представляющей из себя красно-черное дерево. Не знаю, как в std c++ это зовётся, вроде бы тоже Map. Главное - это скорость доступа, она должна быть O(log N).

Симонов Денис In-memory таблица вещь хорошая, но в тройке и так дофига чего ещё делать. Может в каком нибудь 3.1 и будет. Оформи хотелку в трекер.Бесполезняк. Ибо там меня всегда ждёт Шон
Лучше здесь зондировать по-максимуму, пока Светила не скажут вердикт.

Симонов ДенисКстати тут тоже кроется недостаток. Как за памятью такой таблицы следить?То есть ?

dimitrСимонов Денисне мне кажется он совсем без блокировок хочет
грязную запись? ню-ню...Да. Да! Именно так: ГРЯЗНУЮ запись. Чтение из этой структуры МОЖЕТ быть привести к несогласованным результатам. Пусть перечитывают, если "не нравится" - не развалятся.
Для чистых записей есть fixed-таблицы.

dimitrценой блокировки уровня таблицы, а-ля MyISAM? Я уже говорил данунах? :-)оставим даунам дауново... мне бы в страшном бреду не привиделось предлагать лочить всю таблу.
Кстати... а где ты говорил про даунов ? что-то я пропустил, кажется...

ТаблоидЧтение из этой структуры МОЖЕТ быть привести к несогласованным результатам. upated.

miwaonlineТаблоидКстати... а где ты говорил про даунов ? что-то я пропустил, кажется...
"Данунах" - это не о даунах ;)А, да... глаза замылены... но что-то всё-таки навеяло, не знаю даже что именно...

dimitrТаблоидДа! Именно так: ГРЯЗНУЮ запись. Чтение из этой структуры МОЖЕТ привести к несогласованным результатамаффтар, пеши исчо!Чё там не так ? :-)
я спросил именно про структуру, которая должна
* хранить данные, видимые всем коннектам,
* не быть персистентной (т.е. храниться в ней должны только данные, потеря или нарушение согласованности которых не имеет значения для бизнеса) и
* иметь максимальное быстрод-вие, пусть и за счет возможной несогласованности при считывании.

Ну, так что тут "пешать исчо" ? :-)

Ivan_PisarevskyМабыть Таблоид нечто вроде GTT, которое не материализуется на диск, но видно всем коннектам?

Если честно я вообще не понял хотелки.Типа такого. Только чтобы поиск сразу велся только в "индексе", а не так, как сейчас: "сначала лезем в индекс, находим куда дальше лезть в таблице, затем переходим в таблицу и ищем там".

Гаджимурадов Рустамdimitr> ему не нужны переменные, ему нужны таблицы без таблиц

Это другая хотелка. :) А что насчёт неймспейса GLOBAL ?Это та же самая хотелка. Твой "namespace global" - просто строгое научное определение этому :-)

Гаджимурадов РустамЗавтра ты (или кто другой), скорее всего,
захочешь больше - и индексы, и констрейнты (что вполне логично).Кто захочет большего - велкам в мир fixed-таблиц.
Индексы, кстати, я не просил: map-структура, реализованная в виде treemap'a, и есть индекс. Данные достаются сразу из него, никуда дальше лезть не надо.

Гаджимурадов РустамТаблоид> * иметь максимальное быстрод-вие, пусть и за счет возможной несогласованности при считывании.

Несогласованное чтение там, в общем-то, необязательно, AFAIU.Тогда синхронизацию доступа надо ваять. Лишние затраты, да и опять всё станет похоже на мир fixed-таблиц.

dimitrТаблоидТогда синхронизацию доступа надо ваять
ты лучше проспись и с утра подумай, что будет с твоим красно-черным деревом (или любой другой связанной структурой) при параллельном изменении без синхронизации доступапфф... да, сглупил... каюсь :-[
Ладно, пусть дальше Источники Света решают, витать дальше этой идее в воздухе или в топку её.

Гаджимурадов РустамКак ты будешь больше одного атрибута мапить?
Не говоря уже о параллельном доступе.Больше 1 атрибута на ключ ? А что, сейчас в rdb$set_context'e это уже можно сделать ? ;-)
Что касается паралл. доступа, то - да, погорячился я там. Синхр-зация нужна.

Гаджимурадов Рустам> да и опять всё станет похоже на мир fixed-таблиц.

А какие к нему есть претензии, кроме производительности
(и мусора, что тоже частный случай производительности)?А это и есть претензия. Делать ПЯТЬ фетчей для выборки константы из rdb$database - в наш стремительный век не комильфо как бэ...

Гаджимурадов РустамНе говоря уже о том, что задача не ахти какая насущная и
полезная с прикладной т.з.я всего лишь озвучил то, что у нас тут "вдруг" захотели местные пинкертоны-СБшники и радетели за чистоту рядов.