Beefy Boxes and Bandwidth Generously Provided by pair Networks
Keep It Simple, Stupid

Re: A good way to input data into a script w/o an SQL database

by kcott (Archbishop)
on Sep 10, 2023 at 02:00 UTC ( [id://11154354]=note: print w/replies, xml ) Need Help??

in reply to A good way to input data into a script w/o an SQL database

G'day ObiPanda,

As a general rule of thumb, code will change infrequently but data may change often, so keep the two separate.

Your question is extremely vague and it's difficult to provide a more concrete answer. If you were to present even a simple example of your current "code with data" script, I'm sure we could give a much better answer. As it stands, any response will be pure guesswork.

— Ken

  • Comment on Re: A good way to input data into a script w/o an SQL database

Replies are listed 'Best First'.
Re^2: A good way to input data into a script w/o an SQL database
by ObiPanda (Acolyte) on Sep 10, 2023 at 19:52 UTC

    I was just thinking of a way to input the data into an array of hashes from one or more external files which would hold the data. The array is then used to provide some simple configuration options to a program. This script is intended to run both Linux and Windows, obviously changing the paths.

    #!/usr/bin/env perl use strict; use warnings; use autodie; # For Windows my $Subscriptions_Path = "G:/Subscriptions"; my $Phone_Sync = "G:/Sync/PHONE/Main/Music"; my $Temp_Files_Location = "G:/Subscriptions/tmp"; my $Wait_Time = 10; # Subscription DATA sets my @Subscription = ( { Sub_Name => "Morph", Archive_File => "Morph Archive.txt", Lib_Sub_Path => "$Subscriptions_Path/Morph", Phone_transfer => 0 }, ); for (@Subscription) { print "Beginning Subscription Service for $_->{Sub_Name} \n"; print "\nCompleting Subscription Service for $_->{Sub_Name} \n\n\ +n"; sleep int(rand($Wait_Time)); }

      Thanks for posting your sample code. Much clearer now!

      In fact, it spookily reminded me of a node I wrote a while back: Data-driven Programming: fun with Perl, JSON, YAML, XML...

      As you can see from that node, I faced a similar problem to what you are asking about.

      Generally, I'm a fan of defining a table of properties, as you have done, because it helps to separate the code from the data. After asking my question, I ended up leaving the script alone with its table of properties hard-wired in the script. It was very flexible that way and proved to be easy to maintain over many years. Having the build script itself under version control was essential, of course, to allow us to examine changes to our automated builds over time.

      Update: see also: Data Structure References

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://11154354]
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others contemplating the Monastery: (3)
As of 2024-04-18 23:10 GMT
Find Nodes?
    Voting Booth?

    No recent polls found