SPUG: Best practice? DBI connection parameters *not* in Perl code

Mark Mertel mark.mertel at yahoo.com
Thu Apr 8 11:36:53 PDT 2010


and on the other side - ENV variables - most client-server databases already support some type of $ENV{ USER } for their out-of-the-box client tools, i.e. sqlplus, isql, etc.


 ---
Mark Mertel
mark.mertel at yahoo.com




________________________________
From: Brian E. Lozier <brian at massassi.com>
To: SPUG Members <members at seattleperl.org>
Sent: Thu, April 8, 2010 11:26:30 AM
Subject: Re: SPUG: Best practice? DBI connection parameters *not* in Perl code

Regarding YAML -- in my experience, the "YAML" module on CPAN is buggy
and can't properly handle complex structures.  This bit us and we
moved to JSON (this wasn't for configuration).  It should be fine for
simple config data (but may be a bit heavy weight for that).  See the
bug list: https://rt.cpan.org/Public/Dist/Display.html?Name=YAML

It's been suggested to use YAML::Syck, but that's compiling its own
huge list of bugs as well.  Depending on your deployment targets, you
may want to stick with a pure-perl solution, which, I believe,
YAML::Syck isn't.

I've used Config::Fast and Config::General and have been happy with both.

Brian

On Thu, Apr 8, 2010 at 10:53 AM, Skylos <skylos at gmail.com> wrote:
> I'm not entirely sure if its best practice, but my feeling is that I would
> prefer a config file because its a more obvious artifact that can be
> deployed with the application.  As for format, YAML of course.  And here's a
> module especial for that.
>
> http://search.cpan.org/~moconnor/YAML-AppConfig-0.16/lib/YAML/AppConfig.pm
>
> Skylos
>
>
> On Thu, Apr 8, 2010 at 10:45 AM, Michael R. Wolf <MichaelRWolf at att.net>
> wrote:
>>
>> As some DBI-based code is being ported to other machines, I'm having to
>> pass command-line parameters to too many administrative and test programs.
>>  I'd like to change this *once* external to *all* programs and have it apply
>> to them all.  This will have the added benefit of articulating a cleaner
>> differentiation between environments (development, test, production).
>>
>> What's more popular to do this?
>>  - environment variables
>>  - config file
>>
>> In code, and in *theory*, it's a trivial difference...
>>
>>    $db_user = $ENV{db_user} || 'root';
>>        versus
>>    $db_user = $some_config_ref->get_attribute('db_user') || 'root';
>>
>> I'm more interested in how this works in *practice*.  That is, when
>> fielded, which seems to be groked by more end users?  And if the answer is
>> 'config', which of the 2 score and twenty config modules seems to be groked
>> by more end users?
>>
>> Thanks,
>> Michael
>>
>> --
>
>
> --
> "If only I could get rid of hunger by rubbing my belly" - Diogenes
>
> _____________________________________________________________
> Seattle Perl Users Group Mailing List
>     POST TO: spug-list at pm.org
> SUBSCRIPTION: http://mail.pm.org/mailman/listinfo/spug-list
>    MEETINGS: 3rd Tuesdays
>    WEB PAGE: http://seattleperl.org/
>
_____________________________________________________________
Seattle Perl Users Group Mailing List
     POST TO: spug-list at pm.org
SUBSCRIPTION: http://mail.pm.org/mailman/listinfo/spug-list
    MEETINGS: 3rd Tuesdays
    WEB PAGE: http://seattleperl.org/



      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/spug-list/attachments/20100408/e7b6015c/attachment.html>


More information about the spug-list mailing list