Item1411: DirectedGraphPlugin generates new revs on view

If you have this setting in LocalSite.cfg (see http://foswiki.org/System/ForceNewRevision):

$Foswiki::cfg{ReplaceIfEditedAgainWithin} = 0;

and creating a dot with dynamic data, DirectedGraphPlugin will generate new revisions on each view. If you have a couple of them in one page the number of revisions will go sky high. The good thing is that the accompanying attachments aren't updated (the dates of the files don't change), so DirectedGraphPlugin understands correctly that there's no need to update the images. But for some reason DirectedGraphPlugin is making changes on every view. The diff between those revisions only show meta changes.

I don't know if this behaviour is intended, a bug or technically impossible to fix, but it's quite annoying.

Here's a sample dot:

<dot antialias="off" vectorformats="svg ps2" density="300" >
digraph G
{
  fontname="Helvetica";
  center="true";
  regular="true";
  size ="12,10";
  ratio="fill";

  graph [rankdir="RL" label="Revision: %REVINFO{$rev}%" labelloc=t fontsize=20  labeljust=l  bgcolor="#eeeeff"];
  test [label="Test"];
}
</dot>

Note that removing

%REVINFO{$rev}%

removes the problem.

---

This is by design. If any component of the graph changes, then the md5 checksum that determines if the input to the plugin also changes. That causes the plugin to regenerate the attachment. If it did not do this, it would have no way of knowing that the label on the graph has changed.

The way to avoid the changes in attachment metadata is to code the expert configuration parameter -

# **PATH EXPERT**
# Path for plugin to store generated attachments<br>
#  Optional.  If not provided, plugin will manage attachments using the standard Foswiki attachment functions.
#  If not provided, first visit to System.DirectedGraphPlugin will require admin / sudo login for write access, in order to save generated attachments.
#  If set to the /pub path, generated attachments will be invisible to Foswiki topics.
#  This directory must be web readable.  <b>If not set to /pub, web server changes will be required to enable access.</b>
$Foswiki::cfg{Plugins}{DirectedGraphPlugin}{attachPath} = '';

This will cause the plugin to no longer use the Attach API, and the topic revisions will not get updated. The graphs will still be regenerated, since the content between the <dot> tags has changed, but will not be reflected in the metadata. Once you've turned it off in the configure interface, you can turn the attach API back on per topic or web by setting Set DIRECTEDGRAPHPLUGIN_FORCEATTACHAPI = on in your topic, user or web preferences. It cannot be initially disabled from topic settings because of possible security implications.

I had discussed this a bit with other developers. Unfortunately the core API does not provide a "quiet attach" option. Each call to attach is the equivalent of using the attach web interface to add or update an attachment. So this would require core API changes to handle any other way.

I've added some details to the plugin documentation for the next release that explains this behaviour.

-- GeorgeClark - 05 Apr 2009

---

Thanks! I'll try that.

PS: I also fixed the start post, as the the dates of the attachments DO change, my mistake.

-- DurkS - 06 Apr 2009

---

Okay, I tried your suggestion, but I don't seem to get it working. I've set attachPath to /var/lib/foswiki/pub/System/DirectedGraphPlugin/, which does exist and has proper permissions. However the graph isn't regenerated (I don't see changes in /var/lib/foswiki/pub/System/DirectedGraphPlugin/) and the graph images still points to the old location. Concerning the link that doesn't point to the new location, setting attachUrlPath doesn't help, as it replaces only the foswiki/pub part of the URL. Do I miss something?

"I had discussed this a bit with other developers. Unfortunately the core API does not provide a "quiet attach" option. Each call to attach is the equivalent of using the attach web interface to add or update an attachment. So this would require core API changes to handle any other way."

If was just wondering, isn't it possible to save the dot code (from the wiki topic) to a file (or md5) that was used to generate the latest version of the graph, attach it, and use it the next time (on page refresh) to compare whether the dot has changed, before anything is generated. This would prevent unnecessary generation of graphs, and it doesn't matter whether the dot code is changed by hand or was subject to dynamic changes.

-- DurkS - 15 Apr 2009

---

attachPath should be set to the path of the pub directory itself - i.e. /var/lib/foswiki/pub It is the location of the PUB directory, not the location for a specific web/topic. The rest of the path is provided by the web/topic name and inserted by the plugin. when you included Web/Topic in the setting, things probably got all confused.

A MD5 sum is calculated from the dot input. However you included %REVINFO% inside the dot tag, so the diagram does change when the topic rev is changed. It is your input that is changing the dot source which is causing the graph to change. And since "attach API" updates the topic rev, the next view will see yet another rev, resulting in yet another update. You should not include %REVINFO% as part of the graph input if the attach API is used.

The only solution is to use the attachPath. This does work, and will bypass the API. The REVINFO will become more stable, and a new graph should only be updated when a new rev is made of the topic.

The MD5 sums are stored in the working/work_areas/DirectedGraphPlugin directory, named as Web_Topic-hashfile The file is a binary "Storable" object written by perl, but if you look in the file you should be able to recognize the graph names and md5 sums.

-- GeorgeClark - 29 Apr 2009