Конфиг

текстовый файл

> текстовый файл

в ruby проще вместо тупого текстового файла, использовать YAML (Yet Another Markup Language). но у этого способа есть один нехилый минус - мне нужно, чтобы изменения, внесённые в конфиг, сразу отражались на работе приложения...

Реестр.

А причём тут форма хранения, здесь нужно "считывание" приложением конфига при его изменении? Только ещё нах оно нужно?

+1
gconf

> Реестр.

см. чуть ниже

> gconf

решение должно быть кроссплатформенным. ни gconf, ни реестр, ни что-то ещё platform-specific, не подходит. даже не пытайтесь :)

> А причём тут форма хранения, здесь нужно "считывание" приложением конфига при его изменении? Только ещё нах оно нужно?

На ЛОРе всегда знают "как правильно что-то делать". Вот я и спрашиваю, как правильнее мне реализовать "конфиги", которые должны применяться сразу после их изменения.

>Вот я и спрашиваю, как правильнее мне реализовать "конфиги", которые должны применяться сразу после их изменения.

Делов-то, при каждом запросе первым делом считывать конфиг.

> Делов-то, при каждом запросе первым делом считывать конфиг.

Возможно, но запрос к базе данных более легкая задача, чем "загрузить файл и пропарсить".

> чем "загрузить файл и пропарсить".

если размер и время последнего изменения не менялись, то это и не нужно

>если размер и время последнего изменения не менялись, то это и не нужно

А если в один такт времени произошло несколько изменений, а в прошлый раз считывалось не последнее?

> если размер и время последнего изменения не менялись, то это и не нужно

Конечно же я предполагал это учитывать, но всё-же, что лучше: база данных, или файл?

Не парься, используй базу данных, и писанины поменьше, и, в случае большого конфига, работа с базой будет быстрее, чем парсинг линейного файла.

> Не парься, используй базу данных, и писанины поменьше, и, в случае большого конфига, работа с базой будет быстрее, чем парсинг линейного файла.

Спасибо, буду использовать базу данных.

>Не парься, используй базу данных

+1

SQLite

использование базы данных исключит возможность изменения параметров конфига пользователем из редактора:)

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

Куда деть конфиг соединения до бд если конфиг находится в бд:) ?

> Куда деть конфиг соединения до бд если конфиг находится в бд:) ?

Информация, которую я планирую хранить в конфиге, неактуально до момента подключения к базе.

> использование базы данных исключит возможность изменения параметров конфига пользователем из редактора:)

Этого не нужно.

> SQLite

Люди на ЛОРе мало того, что не ходят по ссылкам, так теперь завели новую моду ещё и не читать исходного сообщения :)

База данных уже есть, вопрос ставится такой - стоит ли хранить пары "ключ-значение" в ещё одной таблице, или же следует использовать текстовый файл.

Буду хранить данные в БД. Эта информация неактуальна до подключения.

а если база наipнулась ? или надо по-быстрому перенести типовую конфигурацию на другой проект ? бекапить конфиг надо будет хитрым дампом ?

я бы советовал сначала решить, конфиг нужен или таблица соответствий ключ-значение. Если конфиг, то тут изобретать ничего не надо, а лучше поискать готовый модуль (или как там в руби, гем ?) в котором все будет. Если предполагается > 1к полей которые отдельно от данных сайта не очень то и нужны, то конечно бд.

> а если база наipнулась ? или надо по-быстрому перенести типовую конфигурацию на другой проект ? бекапить конфиг надо будет хитрым дампом ?

Если база не работает, то информация из этих полей будет нафиг не нужна.

> я бы советовал сначала решить, конфиг нужен или таблица соответствий ключ-значение

Нужна таблица соответствий "ключ-значение".

> Если предполагается > 1к полей которые отдельно от данных сайта не очень то и нужны, то конечно бд.

Предподагается << 1000 (<< это не побитовое смещение, а "много меньше", если чо) записей, которые отдельно от данных сайта вообще нафиг никому не сдались :)

тебе однозначно нужна база

cat > $RAILS_ROOT/lib/configuration.rb <<EOF
module Configuration
  # Тут есть два варианта
  # Первый:
  CONFIG_DATA = {
    :base_dir => "/var/www",
    :max_users => 500
  }
  # Второй:
  BASE_DIR = "/var/www"
  MAX_USERS = 500
end
EOF

А потом делаешь include Configuration и Configuration::MAX_USERS.