Hi all, It would be immensely useful for me to be able to use multivalued attributes from SQL xlats. Is this something that is possible? I'm guessing from previous posts that the advice should be "use a programming language" but it seems a shame if we need to do that for multiple row returns from SQL and not for single row returns. Foreach is there for iterating over these, and we already have multivalued attributes supported in request / reply lists... Thanks! Andy
On 22/09/14 15:33, Franks Andy (RLZ) IT Systems Engineer wrote:
Hi all,
It would be immensely useful for me to be able to use multivalued attributes from SQL xlats.
Yeah, that would be handy. I've a few use-cases as well. I currently work around it by pushing the selection logic down into the SQL query, but it's a bit clever/magic and hard to maintain. I have no real love for any of the rlm_$lang modules; they all seem to have super-gnarly edge cases or weirdness :o(
Phil Mayers wrote:
Yeah, that would be handy. I've a few use-cases as well. I currently work around it by pushing the selection logic down into the SQL query, but it's a bit clever/magic and hard to maintain.
I've done the same. It's not pretty.
I have no real love for any of the rlm_$lang modules; they all seem to have super-gnarly edge cases or weirdness :o(
Hmm... 3.0 is better. A LOT better. The SQL and LDAP modules have been completely re-written to make sense. I'm using both modules heavily in production. Alan DeKok.
On 22 Sep 2014, at 11:34, Alan DeKok <aland@deployingradius.com> wrote:
Phil Mayers wrote:
Yeah, that would be handy. I've a few use-cases as well. I currently work around it by pushing the selection logic down into the SQL query, but it's a bit clever/magic and hard to maintain.
I've done the same. It's not pretty.
I have no real love for any of the rlm_$lang modules; they all seem to have super-gnarly edge cases or weirdness :o(
Hmm... 3.0 is better. A LOT better. The SQL and LDAP modules have been completely re-written to make sense.
I'm using both modules heavily in production.
The rlm_$lang modules have a few weird things fixed. rlm_perl should be a bit faster. The main issue, is it's marshalling/un-marshalling every attribute in every request irrespective of whether it's needed or modified. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
Franks Andy (RLZ) IT Systems Engineer wrote:
It would be immensely useful for me to be able to use multivalued attributes from SQL xlats.
Yes.
Is this something that is possible?
Arran and I were discussing that. Most solutions are hard. The code is pretty much welded to using *one* string coming back from string expansions. Allowing for more is... not simple.
I’m guessing from previous posts that the advice should be “use a programming language” but it seems a shame if we need to do that for multiple row returns from SQL and not for single row returns.
I agree.
Foreach is there for iterating over these, and we already have multivalued attributes supported in request / reply lists…
That sounds simple, but the implementation and even configuration file syntax isn't obvious. :( Alan DeKok.
On 22/09/14 16:05, Alan DeKok wrote:
That sounds simple, but the implementation and even configuration file syntax isn't obvious. :(
I've wondered about some dirt-simple rlm_sqlmap like this: sqlmap map1 { sql_instance = sqlmodname update { Attr-Name = row[0][0] Attr-Other = row[1][2] } } Alternatively, just enforce that the SQL query has to return: select attrname, op, val from ... ...i.e. returning request:Foo | := | bar reply:Class | := | baz
Phil Mayers wrote:
Alternatively, just enforce that the SQL query has to return:
select attrname, op, val from ...
...i.e. returning
request:Foo | := | bar reply:Class | := | baz
That's pretty much what Arran and I ended up with. The downside is that we'll have to create a new internal expansion API, as the current one only deals with strings. Then the question becomes what syntax to use, to signal using the new expansion. The input is a string, containing an SQL "select" statement. The output is a list of VPs. So... the only syntax I can thing of which makes sense is: update { reply += "%{sql:SELECT ...}" } i.e. when the destination is a list, the new expansion function is used, instead of the old on. This is easy to discover in the code. This syntax is similar to what Arran already added: update { reply += `/path/to/program` } So there's precedent. I think that functionality will be very useful. I know in the systems I build, I sometimes have to go through contortions to get multiple fields out of SQL and into attributes. Alan DeKok.
participants (4)
-
Alan DeKok -
Arran Cudbard-Bell -
Franks Andy (RLZ) IT Systems Engineer -
Phil Mayers