|
If you've looked at my config, which I sent in a
message to the list a little while ago (and I'll not waste bandwidth on it again
- see: Subject: Difficulty with 2.16), then you can see that I have a
PreClientHook that does some hoop-races to extrapolate (and store in
pseudo-attributes) the integer values for certain attributes so that I can
store those in my accounting database (a shame, since the attributes were
integers in the first place, so this is a double-conversion, but I
digress).
This works great for accounting, and my database
loves being integer-centric. The problem is, I want my <SessionDatabase
SQL> to be integer-centric, too. One would think that just using SQL
statements similar to my accounting statements would use those same
pseudo-attributes and work fine, but they don't. It appears that none of my
pseudo-attributes are set yet at the time of sessiondb processing. Am I correct
in surmising that SessionDatabase happens before PreClientHook? If so,
then a) Why? and b) Is there some higher-up-the-food-chain hook that I can use
for this extrapolation that gets run before the SessionDatabase
stuff?
I know I could get around this quite easily using
extendedMacros.patch from the goodies directory (thanks to Wim Bonis for all the
help your example configs and patches have given me, and to Hugh for
pointing extendedMacros out to me - that's what showed me how to do what I
wanted to do in PreClientHook in the first place), which
would allow me to do a substitution like '%{Acct-Status-Type,integer}'
no matter what the context, but I have a purity problem that makes me
hate patches, because they mean you always have to be aware of
how you're different from the norm and how what Joe is saying might therefore
not apply to you, and you have to remember to put that patch back in (and not
screw it up) every time you upgrade, and..., and..., and etc. So I always like
to achieve my needs via tricks in the config instead of
patching. Unfortunately, if there is no hook before SessionDatabase processing,
I don't see how to do this one strictly through the config.
On a related note, is there a
particular reason that extendedMacros has not simply been integrated into
standard Radiator. All I can think of is that you don't want to give people the
crutch of being able to redundantly call those relatively time-consuming
valNameToNum lookups when it would be much better to do the lookup once and
store it in a pseudo-attribute. If that's the case, then I understand, but in
that case, I need an earlier hook.
Or is my diagnosis wrong in the first place? :)
Just the SessionDatabase clause is included below (as I had expected it
to work), though it is currently commented out. BTW...this insert syntax is
non-standard but works with MySQL. It does just what your intuition tells you it
would do.
Thanks...
Mike
#<SessionDatabase SQL> |
