probably I missed the point but if you are programming in perl I do not see the complexity using Storable. Anyway first of all take a look to a recent thread: Banal Configuration Languages

That said you can have a lot of options beside Storable. The basic Data::Dumper dumps structures that can be eval -ed to have the datastructure back.

If you like more human readable solutions there is YAML or the very common outside perl world JSON

I used something like perl -MYAML -MStorable -e "print Dump @{retrieve ($ARGV[0])};" and perl -e "use YAML (LoadFile); use Storable qw(nstore); @ar = LoadFile($ARGV[0]); nstore(\@ar, $ARGV[1])" to translate YAML and Storable formats.

A plethora of Config::* modules are also available.

You can have comma separated data, in external files but also after the __DATA__ token.. So.. many many options for every taste.

HTH

L*

Thanks! I think I got freaked out by the Perl Cookbook's lengthy example as to how to use file locking with Storable, but now that I've looked at the outstanding documentation for the module I see there's even a lock_store function (and lock_nstore for a more portable though slightly slower solution) that apparently would replace those details (and lock_retrieve). Sometimes the Cookbook (2003) tells me more than I need to know, but Time Marches On and I forget that the state of the art is different than when the second edition of the Cookbook was published 18 years ago. It's still the book I typically reach for first.

Would a comma-separated data format work in my example? Each student "record" has a key that holds multiple values (the student's hobbies), so I'm thinking there isn't a key-to-scalar-value relationship that's required for a CSV format.

Of course CSV would suffice for the example you gave, but it will be a lot more complicated if you have nested structures.

You can combine all the given examples, e.g. use the Database example by using DBD::CSV or next level, tie that CSV database handle with Tie::Hash::DBD and use your hash without changing the rest of your program.

One advice: don't underestimate how "simple" CSV is. *do* use a module, like Text::CSV_XS and/or Text::CSV.

For the hobbies, you would either require a serialization like Sereal or Storable.

If hobbies is the *only* field with multiple values, just drop them at the end of the record, so you can restore them lik

use 5.14.2;
use warnings;

use Text::CSV_XS "csv";
use Data::Peek;

my $data = csv (in => *DATA);
my @hdr  = @{shift @$data};
my $n    = $#hdr;
my @students = map {
    my %h;
    @h{@hdr} = splice @$_, 0 , $n;
    $h{hobbies} = [ @$_ ];
    \%h,
    } @$data;

DDumper \@students;
__END__
name,home_town,age,hobbies
Angie Green,Denver,12,Horses,Painting,Karaoke,Ham Radio
Jamie Brown,London,34
Mark White,Madrid,56,Cooking,Perl,Running
Mary Black,Dublin,30,Baking,Singing,Swimming,Programming Perl
[download]

-->

[
    {   age              => '12',
        hobbies          => [
            'Horses',
            'Painting',
            'Karaoke',
            'Ham Radio'
            ],
        home_town        => 'Denver',
        name             => 'Angie Green'
        },
    {   age              => '34',
        hobbies          => [],
        home_town        => 'London',
        name             => 'Jamie Brown'
        },
    {   age              => '56',
        hobbies          => [
            'Cooking',
            'Perl',
            'Running'
            ],
        home_town        => 'Madrid',
        name             => 'Mark White'
        },
    {   age              => '30',
        hobbies          => [
            'Baking',
            'Singing',
            'Swimming',
            'Programming Perl'
            ],
        home_town        => 'Dublin',
        name             => 'Mary Black'
        }
    ]
[download]

use Text::CSV_XS "csv";

Enjoy, Have FUN! H.Merijn

The suggested Storable is core and should work fine, but there are many more - often much nicer - ways to store persistent hashes. IMHO a more modern and better way is Sereal.

Not that for some, complex keys of code refs in values may cause havoc.

Personally I like to tie my hashes if I need persistence.

With my Tie::Hash::DBD you can even tie your hashes to be stored in a database. See this script (which you should modify to your needs) to benchmark the available methods. this page shows benchmarks for the methods I found on my system (higher values in the last column are better).

NAME
       Storable - persistence for Perl data structures

SYNOPSIS
        use Storable;
        store \%table, 'file';
        $hashref = retrieve('file');
[download]

and
• perldoc Storable
• cpan Storable
• corelist Storable

corelist Storable

Data for 2021-01-23
Storable was first released with perl v5.7.3
[download]

tho I'm not sure I understood the OP .. probably a case of TL;DR

Cheers Rolf
_{(addicted to the Perl Programming Language :)
Wikisyntax for the Monastery}

The thread "Is there any cache mechanism for running perl script" might be an interesting read, where the replies show how to store data structures using Storable, JSON, or Path::Class (the latter only for simple arrays). As for editing a file "in-place", I showed several variations of that in this node.

Note that, with modern databases supporting JSON*, and with modern Perl modules, databases are IMHO pretty nice to work with too. For example, given a Postgres table:

CREATE TABLE students (
    name TEXT NOT NULL PRIMARY KEY,
    hometown TEXT NOT NULL,
    grade TEXT,
    data JSONB NOT NULL DEFAULT '{}'::jsonb
);
[download]

Here's some code using Mojo::Pg showing INSERT, SELECT, and UPDATE:

use Mojo::Pg;

my $pg = Mojo::Pg->new('postgres://localhost:54321/testing')
    ->password('BarFoo');

$pg->db->insert('students', {
    name => 'Bob Kowalski',
    hometown => 'Vero Beach, FL',
    data => { -json => {
        hobbies => [ 'ham radio', 'Python programming', 'running' ],
    } },
});
$pg->db->insert('students', {
    name => 'Kranessa Evans',
    hometown => 'Dallas, TX',
    data => { -json => {
        hobbies => [ 'Perl programming', 'writing', 'polo' ],
    } },
});

my $res = $pg->db->select('students')->expand;
while ( my $rec = $res->hash ) {
    if ( grep {/perl/i} @{ $rec->{data}{hobbies} } ) {
        $pg->db->update('students', { grade=>'A' },
            { name=>$rec->{name} } );
    }
}
$res->finish;
[download]

For a database that doesn't even require a server, Mojo::SQLite has pretty much exactly the same a very similar API as the above (Edit: though I haven't used JSON in SQLite yet).

Update 2: I've modified the connection string in the above to be more useful than using the postgres superuser - and normally one wouldn't hardcode the password of course, see e.g. ~/.pgpass. The following is how I spun up the test database. I'm using port 54321 instead of the default 5432.

$ docker run --rm -p54321:5432 --name pgtestdb -e POSTGRES_PASSWORD=Fo
+oBar -d postgres:13
# wait a few seconds for it to start
$ echo "CREATE USER $USER PASSWORD 'BarFoo'; CREATE DATABASE testing; 
+GRANT ALL PRIVILEGES ON DATABASE testing TO $USER;" | psql postgresql
+://postgres:FooBar@localhost:54321
$ psql postgres://localhost:54321/testing
# log in and create the above table
# run the above Perl script
$ PGPASSWORD=BarFoo psql postgres://localhost:54321/testing -c 'SELECT
+ * FROM students'
$ docker stop pgtestdb
[download]

* Update 3: One more thought here: I'm definitely not advocating just dumping everything in an unstructured JSON blob - one should still try to follow the rules of good database design and normalization as much as possible. But sometimes there are cases where nested data structures can be an advantage, in which case having support in the database for them can be very useful. Update 4: In that regard, erix's reply below!

For a database that doesn't even require a server, Mojo::SQLite has pretty much exactly the same a very similar API as the above

Or standard DBI and DBD::SQLite if you don't feel the need to drag a random web application framework into your code.

Or standard DBI and DBD::SQLite if you don't feel the need to drag a random web application framework into your code.

On the one hand, I understand the sentiment, as loading it does add overhead (although perhaps you should have said so more clearly instead of just expressing your apparent distaste for it), on the other, I think Mojo does have its advantages for simplifying writing code - IMHO it's extremely Perlish. I did list the Mojo solution last (Edit: did you look at the threads I linked to?), since it has the largest learning curve, but I thought it was worth mentioning in the spirit of TIMTOWTDI.

Since the OP does talk about "All the teacher ... wants to do is store the information on a server or other computer so that he or she can call up the students' records at some point in the future -- maybe to browse all the information, or maybe to read or edit a particular student's information ...", using a web interface as a solution is not unthinkable. There's no hint of needing to process billions of records or accesses or other hints that the aforementioned performance overhead is a concern - though it's certainly worth keeping in mind.

For PostgreSQL jsonb one might mention the advantage of json(b)-indexing: it makes access of large json tables fast (rule of thumb: 100x faster - of course, it only matters for large datasets).

(see the PostgreSQL fine manual on JSON-indexing)

Hi, you might like Redis and https://redis.io for this type of thing.

Hope this helps!

Storable or Sereal was the 1st thing that came to my mind but then I realised that they do not allow for searching individual fields (e.g. select) while in-store. You have to read them back into memory and do that there. Additionally, when you want to insert a new record with references or referred by already existing record you need to read all back in memory, add the record, and store. So, (as Choroba said on CB:) "it's hard to make guesses without a detailed spec or use cases." I will add that each solution comes at a price.

OTOH I completely understand your "frustration" that there is no simpler way than creating tables especially to represent complex and nested data structures. But perhaps NoSQL is what you are looking for, see MongoDB::Tutorial. And there are all sort of modules which abstract the tedious parts of SQL away. e.g. DBIx::Class and SQL::Abstract - I am just mentioning those as further reading. I am no way near an expert for these. Other Monks are.

bw, bliako