Hi Rich,

On 03/21/2012 05:15 PM, Rich Graves wrote:
> I fetched custom_example.pm from github. I'm confused about its dependencies. 
> I see that $custom_db_prepared is set in custom_db_prepare(), but the 
> variable is never set and the sub is never run. Huh?

These are used by the worst module that ever existed pf::db (and, to be
fair, I largely contributed to it's current status).

> 
> I can run my $sth = get_db_handle()->prepare inline, but $sth->execute($var) 
> fails.
> 
>     my $sth = get_db_handle()->prepare(<<"    SQL");
>         SELECT affiliation
>         FROM person
>         WHERE pid = ?
>     SQL
> 
> warn "$sth";
> (gives me DBI::st=HASH(0x7eff7b654950) at /usr/local/pf/lib/pf/vlan/custom.pm 
> line 78.)
>     my $query = $sth->execute($user_name);
> warn "$query";
> (gives me 0E0 at /usr/local/pf/lib/pf/vlan/custom.pm line 80.)
>     my ($affiliation) = $sth->fetchrow_array();

Don't do the execute yourself, use the db layer. Here's an example:

my $query = db_query_execute(CUSTOM, $custom_statements,
'statement_name_as_in_prepare', [... parameters ... ])
    || return;

my ($val) = $query->fetchrow_array();
$query->finish();
return ($val);

Otherwise you don't benefit from the db handle re-use, per-thread db
handles (thread safe), the automatic statement retry on failure and the
central logging. Oh and it might also simply not work.

For single rows use db_query_execute and for several rows use db_data.
There are examples all over the place in PacketFence's core code.

For a more straightforwardy answer and fix send a subset of the code to
the list and I'll try to identify your issue.

Another alternative, if you are willing to pay the additional
performance cost of connecting (that I've, honestly, never evaluated)
then you can avoid the db layer altogether and get your own fresh db
handle from DBI (or DBIx::Class) and do your own database stuff from
scratch.

It is an option to consider since we plan (long-term not short) to
improve [drastically] our db layer code and this will affect all users
of said code.

Important to keep in mind also that if you use RADIUS-based access
techniques then the additional connection might matter. There will be
one fresh connection on _each_ RADIUS request that reaches the VLAN
assignment stage.

Hopefully I was helpful ;)
Have a nice day!
-- 
Olivier Bilodeau
[email protected]  ::  +1.514.447.4918 *115  ::  www.inverse.ca
Inverse inc. :: Leaders behind SOGo (www.sogo.nu) and PacketFence
(www.packetfence.org)

------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Packetfence-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/packetfence-users

Reply via email to