Beefy Boxes and Bandwidth Generously Provided by pair Networks
laziness, impatience, and hubris
 
PerlMonks  

Re^3: My preferred way of handling config data in Perl is:

by Anonymous Monk
on Dec 15, 2006 at 18:12 UTC ( [id://590066]=note: print w/replies, xml ) Need Help??


in reply to Re^2: My preferred way of handling config data in Perl is:
in thread My preferred way of handling config data in Perl is:

In same place you store the information that says how to read from the environment / the command line / a config file / etc. ?

At some point, you have to tell the program where to look, and what to look for, no matter what it is you're looking at...

Replies are listed 'Best First'.
Re^4: My preferred way of handling config data in Perl is:
by f00li5h (Chaplain) on Dec 16, 2006 at 01:48 UTC

    True, but something like a database connection string does need to be different for each build-environment you run in, ie you will surely not want the development code connecting to your production database, for example. So I would say that a DSN is a farily important thing to be able to configure,

    .. unless you are going to have a configuration database, to which all code connects, and gets the dsn for it's database from there ... </sarcasm>

    but really, they do something close to this $client, there are constants that come from the database, and a constant to determine the database to go to *shudder*

    @_=qw; ask f00li5h to appear and remain for a moment of pretend better than a lifetime;;s;;@_[map hex,split'',B204316D8C2A4516DE];;y/05/os/&print;
      True, but something like a database connection string does need to be different for each build-environment you run in, ie you will surely not want the development code connecting to your production database, for example.

      There are a lot of ways to handle this sort of thing; some involve external configuration files, some don't.

      One way is to always run the database programs on the same machine as the database server; this means that you can just connect to "localhost", and reach the right database.

      Another method is to have your program detect which host you're running on, and set the database on that basis: when running on machine 'prod', connect to 'prod_database', when running on machine 'test', connect to 'test_database', and so forth.

      You can also just do your database configuration in your DNS and/or /etc/hosts file; a configuration system that you (or your sysadmin) is probably already using. In this method, you always connect to the host "database_server": but that hostname points to different IP addresses on different on different machines.

      Or, as you pointed out, you can just use any number of the other config file methods to specify different results on different machines.... do whatever works for you...

        Anonymous Monk:... use config file or DNS sillyness...

        Yes, those both would do the trick, although I'd prefer the config file, as I'd like to be sure that my hosts were connecting to the right database... just so I can have something in flashing red text to say `this is the development database, and the development code base - expect things to act stupid' so I know to expect stupid behaviours and missing data

        @_=qw; ask f00li5h to appear and remain for a moment of pretend better than a lifetime;;s;;@_[map hex,split'',B204316D8C2A4516DE];;y/05/os/&print;

Log In?
Username:
Password:

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

How do I use this?Last hourOther CB clients
Other Users?
Others having a coffee break in the Monastery: (7)
As of 2024-03-28 10:30 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found