Хочу, чтобы в модуле виделись глобальные переменные скрипта, возможно ли?

Question

[xmolex]

Пишу программу с примерно такой архитектурой:

/global.cgi - инициализирующий скрипт, ловящий переменную с задачей и решающей, какой модуль подгрузить (action.pm)
/lib/module.pm - модуль часто используемых функций
/lib/action1.pm - модуль конкретной задачи
/lib/action2.pm - модуль конкретной задачи
/lib/action3.pm - модуль конкретной задачи

В базе хранятся настройки, которые получает из базы global.cgi и сохраняет их в глобальных хэш. Так вот, необходимо, чтобы этот кеш был виден и в других модулях. Конечно можно передавать ссылку на хэш в каждой функции, но это геморройно, т.к. по идее инициализирует программу global.cgi, который обращается к функции из action.pm, которая пользуется функциями из module.pm и везде нужен этот хэш.
Раньше этот хэш инициализировался в module.pm и импортировался, однако сайт работает под mod_perl и когда запустили копию сайта с другими настройками, получилось, что иногда сайт 1 получал настройки сайта 2. Скорее всего mod_perl видел, что библиотека lib::module уже загружена и импортировал настройки ее, а они допустим первого сайта. Из-за этого решил получение настроек перенести в корневой скрипт global.cgi, однако не понимаю, как передавать настройки модулям. Возможно, можно было просто lib::module сделать объектно-ориентированным и тогда не было бы проблем с mod_perl, но я с ООП не дружу и не знаю, верны ли мои суждения. Знаю, только что есть %ENV, который виден во всех модулях, поэтому есть надежда, что такое можно реализовать. Если у вас есть мысли, как такое сделать, то буду благодарен. Если непонятно написал, напишите, я попробую подробнее объяснить. Уже тонны информации перерыл, но пока безрезультатно.

Answer 1

[ksusha]

Сделайте отдельный кэширующий модуль, куда поместите переменную с кэшем и всякие стандартные методы для работы с ним (get, set итп), далее поместите настройки и закэшированные данные разных сайтов в кэш под разными ключами, и при каждом клике просто назначайте данные по нужному ключу текущими. Т.е. будет глобальный кэш для всех и кэш для конкретного сайта. Можно сделать переменные кэша доступными везде, но лучше сделать доступ к ним через функции кэширующего модуля.

PS Объектно-ориентированность модуля конкретно в этой задаче вам ничем не поможет.

Comments

[xmolex]

Такой модуль у меня и был раньше. Что-то вида:

package lib::module;
require Exporter;
@ISA = qw(Exporter);

my %SETTING = ();
@EXPORT = qw(&SiteSetting);

use strict;
use lib::database;

sub SiteSetting {
   # получаем идентификатор настройки и выводим значение
   my $key = shift || return();
   if (exists($SETTING{$key})) {return($SETTING{$key});}
   else {
     my $sql = sql("SELECT key,value FROM setting WHERE key='$key';");
     if ($$sql[0] eq $key) {
        $SETTING{$key} = $$sql[1];
        return($SETTING{$key});
     } else {return();}
   }
}

Тоесть когда нужна настройка, я подключаю эту библиотеку и делаю my $var = SiteSetting('KEY');
Так-то все меня устраивало, но когда вдруг появился другой сайт с такой же библиотекой, то иногда данные стали проскакивать из другого сайта. Я конечно могу сделать идентификатор сайта и передавать что-то типа my $var = SiteSetting('$sites_id','KEY'), но ведь я всеравно не застрахован, что какой-нибудь жругой человек на этом сервере не станет использовать этот модуль и не назовет свой сайт таким же идентификатором.

[ksusha]

Странная у вас ситуация с организационной точки зрения. У вас shared хостинг? Если всё так как вы описали, у вас 2 выхода — передавать в каждую функцию либо записывать в %ENV. Но так делать не надо, потому что это через одно место.

Вообще кэширование переменных на время жизни воркера в mod_perl — сомнительная фича, скорее похожая на багу, что и демонстрирует ваша ситуация. Поэтому если на сайте нет особой нагрузки, можно обнулять кэш при каждом клике (т.е. кеширование будет только в рамках одного клика), либо (что лучше всего) перенести сайт на VPS и делать там что угодно с кэшированием, не опасаясь зачерпнуть каких-то левых данных.

[xmolex]

К сожалению, проект предполагает использование множества копий сайта с использованием этих библиотек. Хочу вас поблагодарить, т.к. ваша мысль с обнулением помогла. Решил сделать таким образом:

package lib::module;
require Exporter;
@ISA = qw(Exporter);

my %SETTING = ();
my $FLAG = $ENV{DOCUMENT_ROOT}; # в этой переменной храним путь к сайту на сервере
@EXPORT = qw(&SiteSetting);

use strict;
use lib::database;

sub SiteSetting {
   # получаем идентификатор настройки и выводим значение
   my $key = shift || return();
   # если путь вдруг поменялся, то обнуляем наши настройки, т.к. вклинился другой сайт
   if ($ENV{DOCUMENT_ROOT} ne $FLAG) {
     %SETTING = ();
     $FLAG = $ENV{DOCUMENT_ROOT};
   }
   if (exists($SETTING{$key})) {return($SETTING{$key});}
   else {
     my $sql = sql("SELECT key,value FROM setting WHERE key='$key';");
     if ($$sql[0] eq $key) {
        $SETTING{$key} = $$sql[1];
        return($SETTING{$key});
     } else {return();}
   }
}

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

[ksusha]

Рада, что решили проблему. Кстати, для сокращения кода настройки сайта в кэш можно записывать под ключом $ENV{DOCUMENT_ROOT}.

sub SiteSetting {
my $key = shift || return();
my $site_id = $ENV{DOCUMENT_ROOT};

if ( exists $SETTING{$site_id}->{$key}  ) {  
return $SETTING{$site_id}->{$key};  
} else {
my $sql = sql("SELECT key,value FROM setting WHERE key='$key';");
     if ($$sql[0] eq $key) {
        $SETTING{$site_id}->{$key} = $$sql[1];
        return $SETTING{$site_id}->{$key};
} else {  return;  }
}
}

Таким образом к тому же не потрутся настройки остальных сайтов. Собственно, $ENV{DOCUMENT_ROOT} здесь как раз используется в качестве идентификатора сайта для кеширования, о котором я писала выше.

[xmolex]

Я сначала тоже так подумал, но потом производительность проверил в том и другом случае и решил решил на верхнем варианте остановиться.

Answer 2

[Вячеслав Голованов]

Ну, раз хеш с настройками надо передавать — его надо передавать.
Если инициализатор подргужает модули согласно принятым командам, наверно это делается в одном месте скрипта и непонятно, в чём тут такая проблема Ж)
Ну передаст он первым параметром эту ссылку на хэш…

Если будет ООП, тогда это будет не передача параметра функции, а вызов конструктора с инициализацией этими параметрами, в общем форма поменяется.

Как вариант, можно сохранять этот хеш в файле/базе данных, а в модулях загружать.

Comments

[xmolex]

Дело в том, что таких данных может быть довольно много: локальные настройки сайта, html шаблоны сайта, локализованные текстовые сообщения, да и мало ли что еще. Поэтому передача из функции в функцию не подходит.

Answer 3

[afandiman]

Возможно это именно то, что вам нужно
perldoc.perl.org/functions/our.html

Comments

[xmolex]

У вас глобальные переменные (our) в пакетах видятся? У меня нет. Если бы видились, не было бы вопроса.

[vsespb]

our + require Exporter + @EXPORT=