Re: Storable for user preferences

Storable is very good but might be more than is needed for this use case.

If the preferences are all numeric and text values then it might be simpler to use a text based config format. That way users can see and edit their config values using a text editor. There is always the risk they will make a mess of the formatting but you could always add big warnings to the top of the file so it is caveat emptor if they do. (Edit: And fall back to system defaults with a warning when that happens.)

See for example Config::Any for a list of options, e.g. YAML, JSON or INI. Best to avoid the Perl format since it is loaded using do {} so will run any code in the file and is thus a potential security issue.

Comment on Re: Storable for user preferences Download Code

Replies are listed 'Best First'.
Re^2: Storable for user preferences by Fletch (Bishop) on Sep 30, 2023 at 22:12 UTC
Was going to reply with something similar so a strong "seconded" to the above. If you’ve got a large chunk mod;//Storable may win out performance wise, but for a user config YAML or JSON are going to be better choices (human editable plain text FTW). The cake is a lie. The cake is a lie. The cake is a lie.	[reply]
Re^2: Storable for user preferences by Bod (Parson) on Sep 30, 2023 at 22:07 UTC
That way users can see and edit their config values using a text editor Our users would struggle to use a test editor! The only way the preferences will be updated is from a Perl script under my control prompted by user input on a webpage. I did consider using JSON or similar, but that means reading in the entire set of preferences every time I want to access just one of them. Not a deal breaker, but it would probably be better if I didn't have to. Yes, te preferences will be all integers and perhaps strings, mostly just binary options so I shall have a look at Config::Any as a solution. thanks.	[reply]
Re^3: Storable for user preferences by afoken (Chancellor) on Oct 04, 2023 at 12:30 UTC
I shall have a look at Config::Any as a solution If you are using some kind of web environment (e.g. CGI), be VERY careful with write access to the configuration. You need to ensure that no process reads the config file while it is rewritten, or else some settings may get lost. You also need to ensure that at most one process writes the config file at any time. Both can be handled with file locking and atomic renames, but it is easy to implement wrong. It is WAY easier and safer to put the configuration in the database that you already use. Alexander -- Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)	[reply]
Re^4: Storable for user preferences by Bod (Parson) on Oct 12, 2023 at 23:17 UTC
It is WAY* easier and safer to put the configuration in the database that you already use.* Yup! I've gone for a DB solution and it is working well... I guess Storable was a case of Shiny Module Sydrome!	[reply]
Re^5: Storable for user preferences by stevieb (Canon) on Oct 13, 2023 at 06:28 UTC
Re^3: Storable for user preferences by swl (Prior) on Oct 03, 2023 at 22:46 UTC
Not a problem. Reading the other posts on the thread it seems the prefs will be stored centrally anyway, in which case the database approaches would seem the better fit.	[reply]