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

[Daniel Browning]

* Sandy Thomson <sandy at scotwebshops.com> [2004-11-15 04:24]:
> On Tue, 2004-10-26 at 18:59 -0700, Daniel Browning wrote:
> > This bug has subtle but important effects for anyone using [query] & [more].
> 
> Thanks for this, I have noticed this niggling problem for a while here
> and wasn't sure how to solve it.

You're welcome.  Every bit of feedback makes Interchange better.

> > - $obj->{mv_cache_key} = generate_key(substr($page,0,100));
> > + $obj->{mv_cache_key} = generate_key(substr($opt->{query} || $page,0,100));
> 
> This is ok in most cases, but I have some very large queries, sometimes
> with the uniqueness towards the end of the query (and was getting the
> same problem again). So I changed the above line to:
> 
> $obj->{mv_cache_key} = generate_key($opt->{query});
> 
> I understand why the values are truncated but when you have queries with
> large numbers of sub-selects the above might be better. I certainly
> haven't had any problems with it since the change.

You'll find that the patch I applied to Interchange didn't have the 100
character limit (I too found some very long queries).

-- 
Daniel Browning <db at kavod.com> - Kavod Technologies.  Random Fortune:
Finality is death.
Perfection is finality.
Nothing is perfect.
There are lumps in it.