You are here: Foswiki>Tasks Web>Item2033 (27 Jun 2017, MichaelDaum)Edit Attach

Item2033: Invalid topicparents are invisible to DBQUERY{"parent='WebHome'"}

pencil
Priority: Normal
Current State: No Action Required
Released In: n/a
Target Release: n/a
Applies To: Extension
Component: DBCacheContrib
Branches:
Reported By: PaulHarvey
Waiting For:
Last Change By: MichaelDaum
Confirmed in Foswiki 1.0.6 and trunk 4824.


The focus of this bug has changed. Skip to The real problem to see my conclusion the root/orphaned topic issue.

-- PaulHarvey - 22 Sep 2009

Problem

The following is supposed to return only the children of WebHome.
%DBQUERY{"parent='WebHome'" format=" * $topic"}%

Instead it seems to return all orphaned topics (including WebHome), as well as the children of WebHome.

Similarly, I was hoping I'd be able to find orphaned topics using
"%DBQUERY{"parent=''"}%
, however there is no result at all.

Output of %DBQUERY{"parent='WebHome'"}%

(Sandbox web in a reasonably fresh trunk)

Output of %TREE%

%TREE{topic="WebHome" formatting="ullist"}%

Output of %TREE{topic="WebHome"}%

WebHome

-- PaulHarvey - 10 Sep 2009

As discussed on #foswiki, MichaelDaum suggested this fix:

Index: DBCacheContrib/lib/Foswiki/Contrib/DBCacheContrib.pm
===================================================================
--- DBCacheContrib/lib/Foswiki/Contrib/DBCacheContrib.pm   (revision 4685)
+++ DBCacheContrib/lib/Foswiki/Contrib/DBCacheContrib.pm   (working copy)
@@ -413,7 +413,7 @@
 
             # Fill in parent relations
             unless ( $topic->FETCH('parent') ) {
-                $topic->set( 'parent', $Foswiki::cfg{HomeTopicName} );
+                $topic->set( 'parent', '' );
 
                 # last parent is WebHome
             }

Output of %DBQUERY{"parent='WebHome'"}% after patch

Output of %DBQUERY{"parent=''"}% after patch

Conclusion

The above fix makes DBCacheContrib via %DBQUERY{}% work as I expect it to. I suppose it will take some thought to decide whether this fix is appropriate, however. I will run with this patch and assume that somehow, whatever fix gets put into DBCacheContrib, I should be able to get the same results as shown above after this patch.

-- PaulHarvey - 11 Sep 2009

Problem with the simple fix

DBRECURSE (and possibly other DBCachePlugin handlers) fail to work properly against null topic parents.

Working with DBRECURSE as a replacement for TreePlugin, using it the form of %DBRECURSE{web="WebName" topic="" format="...}%

I suspect the infinite recursion protection (which checks to see if a topic is undergoing a second pass), and perhaps other bits of Core.pm.

My first fix looked like this (and there are similar fixes need for other DBCachePlugin handlers):

Index: DBCachePlugin/Core.pm
===================================================================
--- DBCachePlugin/Core.pm   (revision 4960)
+++ DBCachePlugin/Core.pm   (working copy)
@@ -1010,7 +1010,10 @@
 
   #writeDebug("called handleDBRECURSE(" . $params->stringify() . ")");
 
-  my $thisTopic = $params->{_DEFAULT} || $params->{topic} || $baseTopic;
+  my $thisTopic = $params->{_DEFAULT} || $params->{topic};
+  if (!defined $thisTopic) {
+    $thisTopic = $baseTopic;
+  }
   my $thisWeb = $params->{web} || $baseWeb;
 
   ($thisWeb, $thisTopic) = 

However although whereas querying DBRECURSE against a null topic before the fix resulted in no output, now it only produces children of WebHome, which is still not the desired behaviour.

So, only DBQUERY is fixed with the first (DBCacheContrib) patch, and actually I'm getting a "use of uninitialized string in WebDB.pm line 306", which is in a loop over a set of topic names that appears to be checking permissions.

-- PaulHarvey - 18 Sep 2009

The real problem

Okay. We need a spec as to what will be the "root" of all topics.

Previously I had assumed that, seeing as the default is for topics to have no parent (null parent), then the "null" topic would be the root of all topics in a web (including WebHome).

It seems I've been wrong. We want to make it WebHome. And perhaps it's bad to have a topicless root node anyway.

We still need to ensure that DBQUERY and DBRECURSE will actually find all parentless topics (and topics with invalid parents) though, which I don't think is happening. Certainly:

Reproducible problems needing a fix

Query with parent="WebHome" and parent="" won't find topics where %TREE% does, under these conditions:
  • Any parent with a full name="WebName.TopicParent" path
  • Where WebHome is parented to itself (such a WebHome will make all topics under it invisible)
  • Where topics are parented to a non-existent topic

Also:
  • With no parenttopic set, a query of parent='WebHome' includes WebHome in the result set, giving an infinite recursion for a usage such as my nav scheme. I know DBRECURSE works around this by ensuring not to recurse on topics it's already seen, but this is a real problem when using DBQUERY to incrementally ask for the children of topics one a time.

Updating the title of this bug so we head in the right direction.

-- PaulHarvey - 22 Sep 2009

After having reverted my BreadCrumbsPlugin, DBCacheContrib, and DBCachePlugin all back to trunk - I am reminded why I went down this path in the first place!

Querying parent&#61'WebHome' often includes WebHome in the result set, offering infinite recursion with my nav scheme.

I suppose for now I can exclude WebHome from the result set.

-- PaulHarvey - 23 Sep 2009

Having trouble finding time to get this done.

-- PaulHarvey - 14 Oct 2009

Nothing happened here. Closing.

-- Main.MichaelDaum - 27 Jun 2017

ItemTemplate edit

Summary Invalid topicparents are invisible to DBQUERY{"parent='WebHome'"}
ReportedBy PaulHarvey
Codebase 1.0.7
SVN Range Foswiki-1.0.0, Thu, 08 Jan 2009, build 1878
AppliesTo Extension
Component DBCacheContrib
Priority Normal
CurrentState No Action Required
WaitingFor
Checkins
TargetRelease n/a
ReleasedIn n/a
CheckinsOnBranches
trunkCheckins
masterCheckins
ItemBranchCheckins
Release02x01Checkins
Release02x00Checkins
Release01x01Checkins
Topic revision: r7 - 27 Jun 2017, MichaelDaum
The copyright of the content on this website is held by the contributing authors, except where stated elsewhere. See Copyright Statement. Creative Commons License    Legal Imprint    Privacy Policy