Re: [ic] [query] causes [more] to generate non-unique mv_cache_key

[Daniel Browning <suppressed>]

* Daniel Browning <suppressed> [2004-10-26 19:12]:
> This bug has subtle but important effects for anyone using [query] & [more].
> 
> The [more] tag generates a unique mv_cache_key for [list], [search-region],
> etc., but when used with [query], it never does.  This is because it is 
> using an incorrect "message" for generating the key: it uses the first 100
> characters that come after the closing bracket of "[query]", which are never
> unique.
> 
> Here is a patch that causes it to use the "sql" (e.g. "select * from ...") as
> the unique message.  It works for me -- what do you think about it?  Otherwise,
> I think our only option is nothing, i.e. time().
> 
> http://www.icdevgroup.org/~danb/fix_more_cache_key.patch
> 
> 
> +++ Interpolate.pm      2004-10-26 18:50:25.643328006 -0700
> @@ -4547,7 +4547,7 @@
>   $obj->{mv_matchlimit} = $opt->{ml};
>   $obj->{mv_more_decade} = $opt->{md};
>   $obj->{matches} = scalar @{$obj->{mv_results}};
> - $obj->{mv_cache_key} = generate_key(substr($page,0,100));
> + $obj->{mv_cache_key} = generate_key(substr($opt->{query} || $page,0,100));
>   $obj->{mv_first_match} = $opt->{fm} if $opt->{fm};
>   $obj->{mv_search_page} = $opt->{sp} if $opt->{sp};
>   $obj->{prefix} = $opt->{prefix} if $opt->{prefix};

[For the benefit of the archive.]

I've applied a patch to CVS that fixes this problem.

-- 
Daniel Browning <suppressed> - Kavod Technologies.  Random Fortune:
To err is human; to admit it, a blunder.
_______________________________________________
interchange-users mailing list
suppressed
http://www.icdevgroup.org/mailman/listinfo/interchange-users