G'day Bod,
There's three basic types you might consider (possibly others that didn't come to mind when I wrote this):
For scalability and efficiency, a database solution is probably the best. That's based on the 2 to 20 or so preferences that you mentioned; assumes a number of users, now or in the future, totalling in the 100s, 1000s, or more; and also assumes preferences are stored server-side, not client-side. I'd have different advice if those assumptions are incorrect — let us know.
You will need an admin application to create, add, delete and modify the default preferences. It should also be capable of doing the same for user preferences.
In your application which uses the preferences, you'll need to access the default preferences; you only need to access user preferences if they exist. The method of access will, of course, vary; however, you'd probably end up with something like:
my %prefs = (%$default_prefs, %{$user_prefs // {}});
With database storage, you can SELECT just the data you want; for instance, give me "default" and "userX" data.
With Storable, you'd need something like:
my $all_prefs = retrieve('preferences.sto'); my $default_prefs = $all_prefs->{default}; my $user_prefs = $all_prefs->{userX};
With other types of storage, you similarly need to read/load/retrieve a file, then extract the data you want from that.
When changing a preference, you just UPDATE a datum in the database; with Storable, you change a datum in a hash, then rewrite an entire file.
It's possible that there are other, more sophisticated methods with which I'm unfamiliar. See what others have written; there may be better solutions.
— Ken
In reply to Re: Storable for user preferences
by kcott
in thread Storable for user preferences
by Bod
For: | Use: | ||
& | & | ||
< | < | ||
> | > | ||
[ | [ | ||
] | ] |