Tree caches aren't storing numNodes parameter

[GoogleCodeExporter]

What steps will reproduce the problem?
In scripts/retriever.php, isCached 
and in scripts/cacher.php, updateTreeTS

both use only $article and $maxDepth to define a cached tree. You could send an 
entirely different $numNodes parameter, and instead of getting an entirely 
different tree, you'd get the cached one, even though that wasn't the tree you 
requested.

What is the expected output? What do you see instead?
A tree should be defined by three parameters - the name of the article, the max 
articles at each depth (string), and the max depth the tree should go out to.

This needs to be changed in the SQL database, too, as this doesn't match the 
SRS behaviour.

Original issue reported on code.google.com by dylan.ho...@gmail.com on 5 Mar 2011 at 12:16

[GoogleCodeExporter]

I was under the assumption that there was a one-to-one correspondence between a 
particular zoom level (which is the maxDepth value that wikiSearch passes to 
retriever.php) & its numNodes implementation, so I abstained from including 
numNodes since it would be redundant information.

With that said, I can imagine circumstances where we would want to send a 
custom numNodes parameter, and I'm guessing we may choose to do zooming 
differently, so I'll make the appropriate changes.

Original comment by G.Funk1...@gmail.com on 5 Mar 2011 at 12:36

[GoogleCodeExporter]

Just to make sure, since $numNodes tells us $maxDepth, would you still want to 
cache both $numNodes & $maxDepth or just $numNodes? Not really any difference 
either way, but I just want to hear what you think.

Original comment by G.Funk1...@gmail.com on 5 Mar 2011 at 12:42

[GoogleCodeExporter]

Liem had wanted to do it that way, but we specifically defined the tree this 
way to allow the most flexibility in results.

Right now, a tree created with (Bill Gates, "5", 2) is different than (Bill 
Gates, "5,2", 2), etc.

Effectively, that first example will give you the same tree as (Bill Gates, 
"5,5", 2) would. Each node has 5 children. Using "5,2" means that at depth=1, 
you get 5 children, but depth=2, only 2.

It's fine for the zooming functionality to assume correlation between depth and 
the numnodes parameter, since the UI is generating the tree under those 
assumptions. But since we want our code to hypothetically be used by someone 
making an android app, etc, which might have different zoom levels in mind, 
this is an issue.

Original comment by dylan.ho...@gmail.com on 5 Mar 2011 at 12:46

[GoogleCodeExporter]

Didn't see your other comment, sorry.

We should be caching both because of the way the behavior is defined. if the 
array length for numnodes is < maxdepth, then it repeats the last one. If the 
array length is greater, it truncates it.

Original comment by dylan.ho...@gmail.com on 5 Mar 2011 at 12:50