Where to store Application parameters

Hi,

I am considering where to place app parameters for a ROR app I am
building.

I need, with very little frquency, to be able to edit the parameters
from the app. i dont want to hard code anything in file.

What would you recomend as a best practise?

Here are the options I consider:

  1. The database where a row will have fields for all the app param (with
    possible versioning to record changes). Con - a slow db access each time

  2. read/write to file: Slow and would like to avoid writing to directory
    tree. i.e. giving write permission.

  3. Keeping in memory as a global variable - possibly read from db once
    and only changes when updated. - A question that comes to mind is would
    it be possible to keep an object in a global variable ?

TIA,
tuka

The in-memory solution would be the easiest I suppose, but if
volatility is a problem then I wouldn’t suggest it.

How about serializing a settings object to the database using YAML?
Keep the object in memory and then drop it to the database when saved.
Just use the rows to hold revisions of that object. Of course, with
ActiveRecord, that’s arbitrary…you could/should just create a model
and do it that way probably.

The best solution is probably to use environment.rb, but since you
don’t want to hardcode anything, I think maybe the DB is the way to
go.

–Jeremy

On 1/2/07, Tuka O. [email protected] wrote:

it be possible to keep an object in a global variable ?

TIA,
tuka


Posted via http://www.ruby-forum.com/.


My free Ruby e-book:
http://www.humblelittlerubybook.com/book/

My blogs:

http://www.rubyinpractice.com/

Also, if you install memcached and cached_model, then you can use your
parameters as a cached object - it will stay in RAM most of the time and
you’ll only have slow DB calls every once in a while. Other than that it
works exactly the same as normal Active Record.
Jason

Checkout the Settings and AppConfig plugins at the plugin directory
site. They probably have all the code you need.

http://agilewebdevelopment.com/plugins/search?search=settings

Hi,

Thanks guys, your ideas are helpful

I think i will start off with a database access to the parameters and
later refactor to one ofthe alternate solutions for more performace.

Tuka