in reply to Storable for user preferences

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

Replies are listed 'Best First'.
Re^2: Storable for user preferences
by Bod (Parson) on Oct 01, 2023 at 11:00 UTC
    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.

    G'day Ken,

    You are spot on with your assumptions 😀

    Yes, you are right. The database solution is going to be right for this purpose. I had come across Storable mentioned a few times recently both here and in other places and thought it might be a good solution as it keeps the preferences in Perl. But I am not keeping any of the other data within Perl that is held in a database so why shouldn't preferences?

    Perhaps it was shiny penny syndrome...