Hi Rich,
On 03/22/2012 12:46 AM, Rich Graves wrote:
> Ugh. I think it might actually have been working, but I forgot that I need to
> use $node_info->{pid} instead of $user_name when there's no EAP. Undef was
> actually the correct answer.
>
> I do not understand:
>
> 1) Why custom_db_prepare is in @EXPORT. Isn't it defined and only used in
> this module? Threading?
> 2) What is supposed to call custom_db_prepare, and what is supposed to check
> whether $custom_db_prepared is set? It's not in 3.2, is it?
It's accessed through symbolic references from pf::db. Stuff like this:
{
no strict 'refs';
$prepared = ${$db_prepared_var};
}
and this:
> # calling the module's db prepare sub
> # remove restriction on symbolic reference, I need this magic
> {
> no strict 'refs';
> # convoluted statement to call the sub <module>_db_prepare()
> &{$db_prepare_sub}()
> or $logger->error("Can't prepare database statements for
> $from_module. "
> ."Sub $db_prepare_sub does not exist");
> }
are actually poking directly at these variables. So, yes, they are
required and the statements will be prepared by the db layer on first
use. No need for you to run custom_db_prepare().
>
> While testing, I added:
>
> custom_db_prepare() unless ($custom_db_prepared);
>
> to my subroutine, and it might have worked (correctly returning no rows), but
> I'm pretty sure that's not "right."
>
As said above, no need for you to run custom_db_prepare() yourself.
>> 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
>
> That's what I ended up doing (before realizing the $user_name mistake). Since
> it's talking to a local mysql, the overhead is minimal... surely
> insignificant compared to a PEAP/AD login.
>
> If "proper" use of custom_db_prepare requires a newer version of db.pm or
> anything else more involved than vlan/custom.pm, it's not worth it,
It doesn't. It's all there. It seems it didn't work because your query
was wrong after all.
> especially since you're calling it deprecated.
It's not deprecated. Never said so. But we plan to change it one 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
