Miha, > as per docs the 1st match (row) that it is returned from sql wins. > I'll be guessing, when lookup is made with %k, more than one row is > returned but only 1st one is actually fetched. Would it be possible to > combine those rows ascending to the priority e.g 0 is highest priority 7 > lowest, to get the final ruleset. > > Now you are probably wondering why. You could set the defaults and then > override them in deeper levels. NULL value would mean leave value as is, > every other would simply override the previous one. > > Having inheritance you could set up a general rule for whole domain and > override some settings with per-email rules. There would be no need to > copy the values from domain rule to the e-mail rule when such rule is > created by user. End users can usually change just some parts of the > policy (quar level, spam subject and spam points). I'm guessing here but, > the number of policies that match is probably a lot smaller than 8. Well > even if all 8 are returned combining them should be extremely fast.
Sorry for delay - I thought the idea is very good, wondered why it hasn't been implemented yet, and intended to do so and report back. Now that I finally set out to implement it, it turns out that it already works this way and that documentation is wrong. Versions up to 2.2.1 (no longer in 2.3.0) had some field names that did provide a default value for nonexisting fields and stop the search, but even then the NULL/undef value did not stop further scanning of matching records. There could have been an earlier version behaving as it was documented, memory on that is fading me. I'm updating the README.lookups with the following paragraph: A field value NULL is translated to a Perl undef, and is treated the same as a nonexistent field of the specified name. For any field (apart from the only exception field 'local') a record with a NULL/undef/nonexistent field is skipped and search continues with the next, more general, matching record until a defined value is found or all matching records are checked. The only exception is a field named 'local', where a nonexistent field on an otherwise matching record implies a value true - see section "Special handling of optional SQL field 'users.local'" further down. > when lookup is made with %k, more than one row is > returned but only 1st one is actually fetched Not true with current versions. The lookup_sql_field() calls the lookup_sql() with a get_all argument true, resulting in all matching records being returned as a list. > Would it be possible to > combine those rows ascending to the priority e.g 0 is > highest priority 7 lowest, to get the final ruleset. The lookup_sql_field() already works this way as far as I can tell. Thanks for pointing out the documentation problem. If you find that current implementations do not meet your expectations, please let me know. (sorry for responding in English, I expect others too might be interested in a reply) Mark ------------------------------------------------------------------------------ Nokia and AT&T present the 2010 Calling All Innovators-North America contest Create new apps & games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev _______________________________________________ AMaViS-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/amavis-user Please visit http://www.ijs.si/software/amavisd/ regularly For administrativa requests please send email to rainer at openantivirus dot org
