Gary,
> > (28656-01) lookup_sql([EMAIL PROTECTED]) matches, result=(id=>"2",
> priority=>>"10", policy_id=>"1", email=>"[EMAIL PROTECTED]", fullname=>"Peter
> Matulis", local=>>"Y", id=>"2", policy_name=>"Normal",
> <...>
> spam_quarantine_to=>-,
>
> > (28656-01) lookup_sql([EMAIL PROTECTED]) matches, result=(id=>"3",
> priority=>>"7", policy_id=>"3", email=>"@domain.com", fullname=>"domain:
> domain.com", local=>>"Y", id=>"3", policy_name=>"Spambox: domain.com",
> <...>
> spam_quarantine_to=>>"[EMAIL PROTECTED]"
>
> > (28656-01) lookup_sql([EMAIL PROTECTED]) matches, result=(id=>"1",
> priority=>>"0", policy_id=>"1", email=>"@.", fullname=>"Default",
> local=>>"N", id=>"1", policy_name=>"Normal",
> <...>
> spam_quarantine_to=>-,
>
> > But then this:
> > (28656-01) lookup_sql_field(spam_quarantine_to) "[EMAIL PROTECTED]"
> > [EMAIL PROTECTED]
> > Huh?
> I think what you got is the desired behavior.
Indeed.
> This is generally how I perceive what happens (or at least
> what should happen if the database is configured correctly).
> I understand there are differences between
> static and SQL lookups. This table is abbreviated (simplified).
>
> Lookup is performed from the most specific, to the most general.
> First non-empty match wins. ("A match aborts further fetching sequence.")
> U=undef, F1-F6 are fields, '' = empty string, - = NULL.
>
> F1 F2 F3 F4 F5 F6
> [EMAIL PROTECTED] A - - - - -
> @domain B - '' 5 - -
> @. (catchall) C - - 6 - 5
> $something_static U 6 U 7 U U
>
> result for [EMAIL PROTECTED] A 6 '' 5 U 5
>
> "The field value NULL is translated to Perl undef, which according
> to lookup rules implies that the next lookup table (if there are more)
> is to be tried. In plain words, NULL means "this table does not know
> the answer, try the next one"."
>
> This example may or not be correct, so I would appreciate feedback
> if it is not (I don't want to propagate a misconception of mine).
I believe your table and your understanding is correct,
at least for version 2.3.0 and later.
The SQL lookup is somewhat specific because all fields are acquired
with a single SELECT clause. There are two interpretations that
could make sense:
1. scan matching records by priority and stop at first match,
and take the entire matching record, i.e. all its fields;
2. scan matching records but take into consideration only the
field being looked up, undef values would not stop the search.
We had the first interpretation with early versions of amavisd-new.
Later when lookups got the ability to return all matching records,
we switched to the second interpretation. It only makes a difference
when some matching records have a NULL value in a field, while others
have an explicit value, like in the Peter's case.
The amavisd-new-2.3.0 release notes also refer to a related issue
with associative array lookups:
- change hash lookups code to stop a hash search when a matching key
exists, even if the matching result (corresponding hash value) is undef;
this reverts the change made in a release 2.1.0 to a previous behaviour
which is consistent with regexp lookups (but leaves SQL lookups to be
different, continuing the scan to more general entries on a NULL field
value; SQL lookup is specific because all attributes live in the same
record); inconsistency reported by Gary V.;
Sorry for the inconsistency. I think the current behaviour is closer
to what one might expect (lookup on a field only sees that field,
not entire records), although I admit that all may not agree.
I see this is not reflected adequately in README.lookups, I'll change
the relevant paragraph to:
lookup_sql_field() also performs a lookup for an e-mail address against
a SQL map. It first calls lookup_sql() if it hasn't been called yet for
this key, requesting it to return all matching records. Instead of returning
the whole record as lookup_sql does, it returns just a value of one
particular table field, the first one with a defined (non-NULL) value
from the list of matching records (or undef if there are none).
Mark
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
AMaViS-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/amavis-user
AMaViS-FAQ:http://www.amavis.org/amavis-faq.php3
AMaViS-HowTos:http://www.amavis.org/howto/
