Feedback and discussion on DBCacheContrib

-- CrawfordCurrie - 08 Jul 2004

Note: DBCacheContrib is intended for use by plugin authors, not for direct use by end users. If you just want to speed up your existing searches, then go look at VarCachePlugin. If you want to have an interface that allows you to compose and run complex queries over a TWiki database, go look at FormQueryPlugin.

-- CrawfordCurrie - 16 Jul 2004

We need an Operator to compare if a string is greater or lower then other, as we do with > and < between integers. How it can be maked? Can an DBCacheContrib developer show a pat? Thanks!
-- AurelioAHeckert - 11 Feb 2005

In 2 hours I did by my self... but I need the Developer revision.

I'm not a perl programer, but I read some pages and i find wath I think I need in .../lib/TWiki/Contrib/Search.pm.

on the line 66 (Operator precedences "my %prec") i put:

     'LESS_THAN'         => 4,
     'GREATER_THAN'      => 4,
     'LESS_OR_EQUAL'     => 4,
     'GREATER_OR_EQUAL'  => 4,

on the line 83 i change:

  my $bopRE =
    "AND\\b|OR\\b|!=|=~?|<=?|>=?|LATER_THAN\\b|EARLIER_THAN\\b|WITHIN_DAYS\\b|IS_DATE\\b";

to:

  my $bopRE =
    "AND\\b|OR\\b|!=|=~?|LESS_THAN\\b|GREATER_THAN\\b|LESS_OR_EQUAL\\b|GREATER_OR_EQUAL\\b|<=?|>=?|LATER_THAN\\b|EARLIER_THAN\\b|WITHIN_DAYS\\b|IS_DATE\\b";

on the line 219 i put:

    if ( $op eq "LESS_THAN" ) { return ( $val lt $r ) };
    if ( $op eq "GREATER_THAN" ) { return ( $val gt $r ) };
    if ( $op eq "LESS_OR_EQUAL" ) { return ( $val le $r ) };
    if ( $op eq "GREATER_OR_EQUAL" ) { return ( $val ge $r ) };

And I change this:

| <code>&lt;=</code> | field name | integer | Number is <= |

to this:

| <code>&lt;=</code> | field name | integer | Number is &lt;= |

on the line 25 to clear the </td> maked bi the TWiki markup parser.
-- AurelioAHeckert - 11 Feb 2005

Well done, Aurelio!

At some point I'm going to retire this whole syntax and move to proper SQL support. Until then, from a perspective of usability, I'd rather you found a way to overload the comparison operators < > <= etc. If you can't do this, then compatibility with perl (lt, gt, le etc) operators is preferred over LESS_THAN etc.

Don't forget to add tests for the new operators.

Feel free to check in a new version, as long as you promise to extend/run the tests!

-- CrawfordCurrie - 11 Feb 2005

Thanks!

I will try to do this. But I will need your revision.

To do use the operatos > < => <= to numbers and strings we can see the type of variable's values in both side of operator before do someting like if ( $op eq "OPERATOR" ) { return ( $val PerlOperator $r ) };.

But... I do not know a way to know the type of a value. Exist something like isNumber() in perl?

-- AurelioAHeckert - 11 Feb 2005

Ok. I found a way.

    # Check if it have numeric values in both sides:
    my $isNum = 0;
    if ( ( ($val+0) eq $val ) && ( ($r+0) eq $r ) )  {
      $isNum = 1;
    } # I don't know if is this the best way, but it works.

    if ( $op eq "=" )  { return ( $val =~ m/^$r$/ ) };
    if ( $op eq "!=" ) { return ( $val !~ m/^$r$/ ) };
    if ( $op eq "=~" ) { return ( $val =~ m/$r/ ) };
    #if ( $op eq ">" )  { return ( $val > $r ) };
    #if ( $op eq "<" )  { return ( $val < $r ) };
    #if ( $op eq ">=" ) { return ( $val >= $r ) };
    #if ( $op eq "<=" ) { return ( $val <= $r ) };

    if ( $op eq ">" ) {
      if ( $isNum ) { return ( $val > $r  ); }
      else          { return ( $val gt $r ); }
    }
    if ( $op eq "<" ) {
      if ( $isNum ) { return ( $val < $r  ); }
      else          { return ( $val lt $r ); }
    }
    if ( $op eq ">=" ) {
      if ( $isNum ) { return ( $val >= $r ); }
      else          { return ( $val ge $r ); }
    }
    if ( $op eq "<=" ) {
      if ( $isNum ) { return ( $val <= $r ); }
      else          { return ( $val le $r ); }
    }

I cut of the first idea (LESS_THAN, GREATER_THAN, LESS_OR_EQUAL, GREATER_OR_EQUAL) and upload the changed Search to this topic.

-- AurelioAHeckert - 11 Feb 2005

Crawford, I made some enhancements to the NewContribTemplate. With this I changed the DBCacheContrib topic text:

• Heading on top, followed by short description
• Added SHORTDESCRIPTION in "Settings" section
• Added a note to the "Installation Instructions" section
• Added link to GPL in "License" table row
• Added "Appraisal" table row
• Fixed heading levels (use level one only once on top)

Could you take that into the next release of the package?

-- PeterThoeny - 22 Mar 2005

Hello I need help, I can see that the sum function used in the FormQueryPlugin is not working any longer. It can see that now the WebDB has changed since the previous version. The sum is now returning 0 for a Query result on a column specified. However the example of attachments is an specific array and that one works ok.

Basically I need to be able to so domething as follows:

%FORMQUERY{name=AllQuery search="Project=~'ProjectID005PolaRxSW3dot1'" moan="off"}% %FORMQUERY{name=AllQueryDay query=AllQuery search="itdEffortUnit=~'day'" moan="off"}% %SHOWQUERY{ query=AllQueryDay header="|*Topic*|*Effort*|*itdEffortUnit*|*itdRealEffort*|" format="|$topic|$Effort|$itdEffortUnit|$itdRealEffort|" }%

All query: %SUMFIELD{query=AllQuery field="Effort"}%

Before this was working ok.

-- GustavoAdolfoLopez - 22 Mar 2005

Gustavo, without seeing the topics you are trying to work on, it is hard to comment. But I can tell you that summing of columns is working. Note that this is a function on tables and your query above does not look like you are dealing with tables.

-- ThomasWeigert - 12 Jun 2005

Just FYI... While trying to fix that the DBCache functions did not deal with embedded queries (the field[?search] syntax described in FormQueryPlugin) I got tired of struggling with the included parser (in particular, since this parser handles only binary and unary expressions, and the above is either nullary or more complex, depending on how you lex it). I replaced this parser with a table driven parser that can handle LALR-1 grammars. This will make it much easier to switch syntax later on...

-- ThomasWeigert - 12 Jun 2005

In the attached update to the DBCacheContrib, use of SpreadSheetPlugin to perform calculations on the retrieved data is supported. As the date manipulations can be done using this facility and such will be more consistent with other uses of TWiki, the date manipulating functions have been removed.

-- ThomasWeigert - 07 Jul 2005

Fixed updating of parent upon reload in the presence of the cache. Now all test cases pass...

-- ThomasWeigert - 09 Jul 2005

There's a new version in svn that has been reorganized massively. However it has not been released on TWiki.org. Therefore I built one from svn and attached it here: DBCacheContrib-svn.zip. Note, that the current DBCachePlugin and thereby the BlogPlugin depend on the newest DBCacheContrib.

-- MichaelDaum - 01 Feb 2006

Uploaded a new release.

-- MichaelDaum - 14 Feb 2006

Oops, also here all my changes are gone. Please check the Dev topic once in a while.

Small detail: Here and in other recently updated topics, the Contrib Info table has cells in the left column left and right justified. It is supposed to be all right justified.

-- PeterThoeny - 28 Feb 2006

Peter, please note that changing stuff either only in the svn repository or only on twiki.org is bad.

-- MichaelDaum - 01 Mar 2006

This contrib is listed in the ContribPackage index page, but there is no indication what it does. The contrib needs a SHORTDESCRIPTION.

-- PeterThoeny - 07 Mar 2006

While I was trying to install DBCachePlugin, I got these messages.

Even after I install the newest DBCacheContrib in twiki.org, there is still the error message.

If there is anyone know how to solve this problem?

########################################################## Checking dependency on TWiki::Contrib::DBCacheContrib.... Bareword found where operator expected at (eval 74) line 1, near "$ver Dakar" (Missing operator before Dakar?) * DBCachePlugin depends on perl package TWiki::Contrib::DBCacheContrib Dakar which is described as "Required" But when I tried to find it I got this error:

9303 is currently installed: syntax error at (eval 74) line 1, near "$ver Dakar "

-- KuoFengTseng - 29 Apr 2006

It looks like someone checked in a syntax error. You should be able to ignore it, as long as you resolve the dependencies manually.

-- CrawfordCurrie - 30 Apr 2006

To the maintainer: Could you please add a SHORTDESCRIPTION setting so that the contrib is listed with explanation in the ContribPackage table?

-- PeterThoeny - 20 May 2006

I looked at integrating Thomas' changes, but I can't determine which version of the source they are based on. Without a diff it's very difficult to work out what is supposed to change. So I gave up.

-- CrawfordCurrie - 03 Sep 2006

Crawford, whatever you need. Let me know... I have moved this to twiki4...

-- ThomasWeigert - 03 Sep 2006

uc and lc ... good extensions, but I already had done this earlier, unfortunately in a different way... we really need to get our versions to synchronize....

-- ThomasWeigert - 20 Sep 2006

Thomas, what is the main block in the road to merge your's and the currently released DBCacheContrib?

-- MichaelDaum - 23 Sep 2006

I guess this is what needs to be done:

• I need to run all the original test cases to see whether they all pass.
• In cases where there were changes we need to discuss how to deal with this
• Then the combined version has to be produced

I think you and I are the only users of DBCacheContrib in a large scale... I'll try to make progress this weekend...

-- ThomasWeigert - 23 Sep 2006

Michael, I'll start to collect differences that we need to work around...

Search.pm is now a table driven parser, generated with a perl version of yacc. This gives a much easier way of extending the grammar, and of getting it right, but it caused the following problem: The parser code that is generated uses a new function. As I did not want to mess with the generated code, I changed the creator for a search module. Consequentially, whenever you would say in the Currie version

  my $search = new TWiki::Contrib::DBCacheContrib::Search("f1='50'");

you would say the following in the Weigert version:

  my $search = create Search("f1='50'");

The parser, by the way, is attached at search.yp for your reference.

The grammar is defined somewhat more restrictive than the Currie grammar. The biggest difference is that literals are always inside single quotes, where the Currie grammar allows, under certain circumstances these quotes to be omitted. For example, the above Search could be written in the Currie vesion also as

  my $search = new TWiki::Contrib::DBCacheContrib::Search("f1=50");

(note the omitted quotes around 50). I might be able to play with the grammar to get that to work, but I think it is better to be more precise.

• no, 50 is not equivalent to '50'. 50 is a number. '50' is a string. You can't use > on '50' (well you can, but that's because perl is too clever for it's own good) - CC
• Well, depends. This is not really a perl thing, but one of the language of DBCC. If the language says that the terminal symbol on the right is always surrounded in quotes, it will be (Weigert version). If the grammar says the terminal symbol is either a numeric literal or a string in quotes (Currie version), it will be that way. Which one makes more sense depends on what is more consistent with the rest of TWiki, not perl. Note that in the examples provided in the documentation topic for the FormQueryPlugin, everything, numerics and strings are shown in strings. Note that you do not need to disambiguate the lexicals, as the operators already are typed (and perl does not care anyways). -- TW
• oh gosh - let's not go there, because holding TWiki up as an example of what is consistent is a recipe for disaster. TWiki supports both quoted and unquoted values, does not have a strategy for quote-escaping, is really not a good syntax to aspire to. I would rather be driven by SQL and/or XPath in making syntax decisions. Of course SQL doesn't support ambiguous lexicals, but does support both integer and string terminals. Note that there are a number of uses of expression parsers - %IF is one example - that make me think we should abstract out a standard expression parser for use by TWiki modules. On balance I think I'd rather do that than import a dependency on a yacc-style parser (which sounds like overkill for simple expressions, TBH)
• Well, let's agree on the syntax for these expressions, before we worry about the appropriate tool to parse them. A consistent expression parser in TWiki would be wonderful, just as a consistent attribute parser was a great addition AttrDotPm. As for syntax, we should look at the user level though, e.g., how things are used in FormQueryPlugin, not at the test cases.

I have not worked on Archive.pm as the CPAN storable module is much better.

• agreed - though I was moving towards replacing Storable with TDBs (see TdbContrib) - CC

As I integrated the ability to call =%CALC% from SpreadSheetPlugin, I have not supported the less powerful, but equivalent date comparison functions. So instead of using

date IS_DATE '3 jul 1960'

one would use

$CALC( "$TIME($T(date))" ) = $CALC( "$TIME(3 jul 1960)" )

Admittedly, for these simple situations this is more awkward, but it avoids having to learn yet another set of commands. It would not be a problem to support the date functions, however.

• Assumes you know the SpreadsheetPlugin commands.... and I for one don't; I constantly have to refer back to the doc. I do not want to lose the date comparison functions, limited as they are. - CC

The Currie version just added operators to lowercase and uppercase strings. The Weigert version supports a parameter to Search::matches which allows comparisons to be either case sensitive or case insensitive. The latter is more consistent with the TWiki search.

• Agreed - CC

The above is all the cases that show up in the test suite. I think it is an exhaustive list. Could you please comment how all this would affect DBCachePlugin.

Above does not discuss additional functionality, just changes in behavior from the Currie version.

-- ThomasWeigert - 24 Sep 2006

Crawford, a question: Is there an intention that the DBCacheContrib supports nested matches? As an example, should a search pattern such as

[? Owner =~ [? Firstname = 'Jackson'][0].Lastname ]

be handled? I realize above is contrived, but...

-- ThomasWeigert - 30 Sep 2006

I add some new functions for search by Date.. Here is the patch.

--- TWiki/Contrib/DBCacheContrib/Search.pm-orig Tue May 20 11:20:31 2008
+++ TWiki/Contrib/DBCacheContrib/Search.pm      Tue May 20 11:19:26 2008
@@ -72,7 +72,9 @@
     '>' => { exec => \&OP_greater, prec => 4},
     '<' => { exec => \&OP_smaller, prec => 4},
     'EARLIER_THAN' => { exec => \&OP_earlier_than, prec => 4},
+    'EARLIER_EQUAL' => { exec => \&OP_earlier_equal, prec => 4},
     'LATER_THAN' => { exec => \&OP_later_than, prec => 4},
+    'LATER_EQUAL' => { exec => \&OP_later_equal, prec => 4},
     'WITHIN_DAYS' => { exec => \&OP_within_days, prec => 4},
     'IS_DATE' => { exec => \&OP_is_date, prec => 4},
     '!' => { exec => \&OP_not, prec => 3},
@@ -88,7 +90,7 @@
   );
 
 my $bopRE =
-  "AND\\b|OR\\b|!=|=~?|<=?|>=?|LATER_THAN\\b|EARLIER_THAN\\b|WITHIN_DAYS\\b|IS_DATE\\b";
+  "AND\\b|OR\\b|!=|=~?|<=?|>=?|LATER_THAN\\b|LATER_EQUAL\\b|EARLIER_THAN\\b|EARLIER_EQUAL\\b|WITHIN_DAYS\\b|IS_DATE\\b";
 my $uopRE = "!|[lu]c\\b";
 
 my $now = time();
@@ -397,6 +399,25 @@
   return ( $lval > $rval )?1:0;
 }
 
+sub OP_later_equal {
+  my ($r, $l, $map) = @_;
+
+  my $lval = $l->matches( $map );
+  if ($lval !~ /^-?\d+$/) {
+    require Time::ParseDate;
+    $lval = Time::ParseDate::parsedate( $lval );
+  }
+  return 0 unless( defined( $lval ));
+  
+  my $rval = $r->matches( $map );
+  if ($rval !~ /^-?\d+$/) {
+    require Time::ParseDate;
+    $rval = Time::ParseDate::parsedate( $rval );
+  }
+  return 0 unless( defined( $lval ));
+  return ( $lval >= $rval )?1:0;
+}
+
 sub OP_earlier_than {
   my ($r, $l, $map) = @_;
 
@@ -414,6 +435,25 @@
   }
   return 0 unless( defined( $lval ));
   return ( $lval < $rval )?1:0;
+}
+
+sub OP_earlier_equal {
+  my ($r, $l, $map) = @_;
+
+  my $lval = $l->matches( $map );
+  if ($lval !~ /^-?\d+$/) {
+    require Time::ParseDate;
+    $lval = Time::ParseDate::parsedate( $lval );
+  }
+  return 0 unless( defined( $lval ));
+  
+  my $rval = $r->matches( $map );
+  if ($rval !~ /^-?\d+$/) {
+    require Time::ParseDate;
+    $rval = Time::ParseDate::parsedate( $rval );
+  }
+  return 0 unless( defined( $lval ));
+  return ( $lval <= $rval )?1:0;
 }
 
 sub OP_is_date {

-- KuoFengTseng - 20 May 2008

I have had the FormQueryPlugin running successfully, but I've now upgraded to TWiki 4.2 (BIG mistake) & I get many different errors, for example:

%FORMQUERY{extract="attachments" name="all" search="" web="TWiki"}% :Plugin initialisation failed %FORMQUERY{name="big" query="all" search="size>'10240'"}% :Plugin initialisation failed %SHOWQUERY{format="|$_up.web.$_up.name|$name| $percntCALC{$dollarROUND($dollarEVAL($size / 1024), 1)k}$percnt|$percntCALC{$dollarFORMATTIME($date, $dollarday $dollarmon $dollaryear)}$percnt|" query="big"}% :Plugin initialisation failed 

From the Plugin topic itself. I have tried reinstalling it, and this contrib & even installing the DBCachePlugin but nothing works. I used the install from configure, but my installation is old & doesn't quite conform to the rigid directory structure that the configure script & extender.pl seem to want (but that is a different issue). I installed DBCachePlugin and lo! I got a search result on the plugin map - but a "map error" on every other page.

Does this all work with 4.2? Any ideas where I should start to fix it?

-- ChrisHogan - 09 Jul 2008

Yes, it does. I could say more, if we had some error.logs.

A "map error" most probably is an error in your search query.

-- MichaelDaum - 09 Jul 2008

HI Michael - the map error came on every page (other that the DBCachePlugin page itself. I was worried that the contrib was broken with 4.2 for some reason. I'll examine the error logs & see what I can find

-- ChrisHogan - 09 Jul 2008

I found a block in the warning file:

| 09 Jul 2008 - 08:31 | ERROR: bad Map expression at   at /var/www/brightcarvings.com/TWiki/lib/TWiki/Contrib/DBCacheContrib/Map.pm line 126.
 at /var/www/brightcarvings.com/TWiki/lib/TWiki/Contrib/DBCacheContrib/Map.pm line 126
   TWiki::Contrib::DBCacheContrib::Map::get('TWiki::Contrib::DBCacheContrib::Map=HASH(0x337dc00)', ' ', 'undef') called at /var/www/brightcarvings.com/TWiki/lib/TWiki/Contrib/DBCacheContrib/Map.pm line 114
   TWiki::Contrib::DBCacheContrib::Map::get('TWiki::Plugins::DBCachePlugin::WebDB=HASH(0x32d2e40)', 'CreateNewOrganisation ') called at /var/www/brightcarvings.com/TWiki/lib/TWiki/Contrib/DBCacheContrib.pm line 235
   TWiki::Contrib::DBCacheContrib::_onReload('TWiki::Plugins::DBCachePlugin::WebDB=HASH(0x32d2e40)', 'ARRAY(0x231ca80)') called at /var/www/brightcarvings.com/TWiki/lib/TWiki/Contrib/DBCacheContrib.pm line 331
   TWiki::Contrib::DBCacheContrib::load('TWiki::Plugins::DBCachePlugin::WebDB=HASH(0x32d2e40)') called at /var/www/brightcarvings.com/TWiki/lib/TWiki/Plugins/DBCachePlugin/WebDB.pm line 47
   TWiki::Plugins::DBCachePlugin::WebDB::load('TWiki::Plugins::DBCachePlugin::WebDB=HASH(0x32d2e40)') called at /var/www/brightcarvings.com/TWiki/lib/TWiki/Plugins/DBCachePlugin/Core.pm line 1099
   TWiki::Plugins::DBCachePlugin::Core::getDB('Public') called at /var/www/brightcarvings.com/TWiki/lib/TWiki/Plugins/DBCachePlugin/Core.pm line 130
   TWiki::Plugins::DBCachePlugin::Core::getTopicTitle('Public', 'HMWComputingLimited') called at /var/www/brightcarvings.com/TWiki/lib/TWiki/Plugins/DBCachePlugin/Core.pm line 89
   TWiki::Plugins::DBCachePlugin::Core::renderWikiWordHandler('HMWComputingLimited', 'undef', 'Public', 'HMWComputingLimited') called at /var/www/brightcarvings.com/TWiki/lib/TWiki/Plugins/DBCachePlugin.pm line 97
   TWiki::Plugins::DBCachePlugin::renderWikiWordHandler('HMWComputingLimited', 'undef', 'Public', 'HMWComputingLimited') called at /var/www/brightcarvings.com/TWiki/lib/TWiki/Plugin.pm line 266
   TWiki::Plugin::invoke('TWiki::Plugin=HASH(0x12410b0)', 'renderWikiWordHandler', 'HMWComputingLimited', 'undef', 'Public', 'HMWComputingLimited') called at /var/www/brightcarvings.com/TWiki/lib/TWiki/Plugins.pm line 344
   TWiki::Plugins::_dispatch('TWiki::Plugins=HASH(0xa7ca30)', 'renderWikiWordHandler', 'HMWComputingLimited', 'undef', 'Public', 'HMWComputingLimited') called at /var/www/brightcarvings.com/TWiki/lib/TWiki/Plugins.pm line 865
   TWiki::Plugins::renderWikiWordHandler('TWiki::Plugins=HASH(0xa7ca30)', 'HMWComputingLimited', 'undef', 'Public', 'HMWComputingLimited') called at /var/www/brightcarvings.com/TWiki/lib/TWiki/Render.pm line 519
   TWiki::Render::internalLink('TWiki::Render=HASH(0x1f48e90)', 'Public', 'HMWComputingLimited', 'HMWComputingLimited', '', 1, '', 'undef') called at /var/www/brightcarvings.com/TWiki/lib/TWiki/Render.pm line 659
   TWiki::Render::_handleWikiWord('TWiki::Render=HASH(0x1f48e90)', 'Main', 'CreateNewOrganisation', ' ', 'undef') called at /var/www/brightcarvings.com/TWiki/lib/TWiki/Render.pm line 1130
   TWiki::Render::getRenderedVersion('TWiki::Render=HASH(0x1f48e90)', '|*FORM FIELD <nop>OrganisationName*|OrganisationName|Public.H...', 'Main', 'ChrisHogan') called at /var/www/brightcarvings.com/TWiki/lib/TWiki/UI/RDiff.pm line 77
   TWiki::UI::RDiff::_renderCellData('TWiki=HASH(0x60dfc0)', '%META:FIELD{name="OrganisationName" attributes="" title="<nop...', 'Main', 'ChrisHogan') called at /var/www/brightcarvings.com/TWiki/lib/TWiki/UI/RDiff.pm line 287
   TWiki::UI::RDiff::_renderSequential('TWiki=HASH(0x60dfc0)', 'Main', 'ChrisHogan', 'c', '%META:FIELD{name="OrganisationName" attributes="" title="<nop...', '%META:FIELD{name="OrganisationName" attributes="" title="<nop...') called at /var/www/brightcarvings.com/TWiki/lib/TWiki/UI/RDiff.pm line 354
   TWiki::UI::RDiff::_renderRevisionDiff('TWiki=HASH(0x60dfc0)', 'Main', 'ChrisHogan', 'ARRAY(0xc80fc0)', 'sequential') called at /var/www/brightcarvings.com/TWiki/lib/TWiki/UI/RDiff.pm line 495
   TWiki::UI::RDiff::diff('TWiki=HASH(0x60dfc0)') called at /var/www/brightcarvings.com/TWiki/lib/TWiki/UI.pm line 159
   TWiki::UI::__ANON__() called at /var/www/brightcarvings.com/TWiki/lib/CPAN/lib//Error.pm line 379
   eval {...} called at /var/www/brightcarvings.com/TWiki/lib/CPAN/lib//Error.pm line 371
   Error::subs::try('CODE(0x60df50)', 'HASH(0x1f3bbd0)') called at /var/www/brightcarvings.com/TWiki/lib/TWiki/UI.pm line 197
   TWiki::UI::run('CODE(0xa6d210)', 'diff', 1) called

-- ChrisHogan - 09 Jul 2008

Thanks, Chris! I will take a look at it. My next guess is that you have modified a twiki topic manually on file-level and that the cache is having problems with the format of the topic now. I remember Lynnwood had the same problems some time aggo. So I removed all die Bad map ... AFAICS. Maybe some other circumstance might still produce this situation. Please, if you have found the topic that DBCacheContrib stumbles accross - if that's the cause of the problem - then don't just fix it, preserve the topic and attach it here, so that I can use it as a test case to make this thing more robust.

-- MichaelDaum - 10 Jul 2008

Hi Michael, I'll have a go - some topics seem to be mentioned quite often in the errors & I've quite a complex setup

I'll try to get you a smaple set, but I'm on holiday from tomorrow so don't assume I'm ignoring you!

-- ChrisHogan - 10 Jul 2008

Alright, enjoy your holidays, Chris.

-- MichaelDaum - 10 Jul 2008

This is a bit odd. Copied a sample FORMQUERY & it worked fine, so I looked at the logs & one topic seemed to stand out in the errors, so I moved it from the web where I was getting the Form Query failure & yes it all started to work.

This puzzled me a bit, as the offending topic was a simple "create" - a little html form, not very complex. I moved it back to my work web - and the queries still work! All my DBCacheContrib problems are gone.

Could this just be a caching problem of some kind?

-- ChrisHogan - 21 Jul 2008

Next version won't have a "die bad Map expression" anymore. Most probably, you have a value in one of your TOPICPARENT metadata that is no valid "map expression", i.e. a topic name. For instance a

%META:TOPICPARENT{name="%25WIKINAME%25"}%

will trigger this die.

-- MichaelDaum - 21 Jul 2008