Tags:
create new tag
, view all tags

Module name TWiki::Store StoreDotPm
Location TWIKIROOT/lib/TWiki/Store.pm
Summary This module implements the storage backend
Primary Author NicholasLee / JohnTalintyre
CVS history CVS:lib/TWiki/Store.pm
CVS alpha CVSget:lib/TWiki/Store.pm
Contributing authors (see CVS History)
Is Class NO
First Release to be filled out
File Hierarchy
  TWIKIROOT
  lib
  TWiki
  Store.pm

Purpose

This module hosts the backend implementation. Currently it is hardwired to RCS-like backends.

Used by

This module is primarily used by FuncDotPm and TWikiDotPm.

Please see CodevDocumentationProject and CodevDocumentationProjectDev to comment on the format of these pages.

Note: Below documentation is extracted from the currently installed TWiki::Store Perl module, which is done by the PerlDocPlugin

%PERLDOC{"TWiki::Store"}%

Contributors:
-- MartinCleaver - 23 Jun 2002
-- PeterThoeny - 02 Feb 2004

Discussions

I've resurrected this topic to raise the question of feasibility of using CgiWiki's backend.

I see the CgiWiki classes as a fast route to implementing ModularStorageBackend

-- MartinCleaver - 06 May 2003

I'm unclear how the existance of another Wiki's backend code would help with TWiki. A green field development, yes, converting an existing code base with lots of users that want less upgrade hassle, I don't see how.

If someone really wants to try a new backend I don't think it's that difficult. Certainly the hooks are there for trying something instead of RCS, as there are already two independent implementions - mind you finding all the code in TWiki core and plugins that assumes the current file system mechanism will be a fair bit of work.

-- JohnTalintyre - 07 May 2003

My analysis of performance wrt settings has led me to examine Store.pm closely since Prefs.pm calls in it heavily.

A key observation is that 90% of the time, most of Store.pm is not used. This offers an oportunity for redesign and repartitioning.

The 90% (or better) case is driven by bin/view. I estimate on my own behaviour, and I'm a pretty regular "editor", that I view at least 10 pages - get real! more like 50 - for every one edited.

The code in Store.pm has parts that do read, parts that do write, parts that manipulate the revision store (via _getTopicHandler) and parts that move stuff around. The 90% case only reads the curent revision, which is rapidly accessible since it is the topic.txt file.

Given this:

  • The other code should be load-on-demand or in a seperate module
  • The common situation can be optimized

I don't guarentee much peformance improvement, but thinking about only loading the code that has to be run is a good exercise and usually uncovers design ideosyncracies. Thinking about partitioning and thinking about whether lib/TWiki.pm has to =use everything in lib/TWiki/ will give insights into performance.

-- AntonAylward - 14 May 2003

Testing ideas would be soooooo much easier if this were object oriented already, I'd just have to use over-rides.

I can't persuade anyone to do a OO redesign for me, can I?

-- AntonAylward - 14 May 2003

I promised to do one last year when BeijingRelease was still imminent in June. I had plenty of time then. Now I don't, and so subsequently retract my offer. (For anyone wondering why my contributions peaked again recently, I've just had a two week recess in my MBA course).

TWiki does need a redesign, it also needs a CairoCoreTeam who fed up and discontent with the existing design, not both tired and happy with making small changes. The fact that TWikiAlphas are so solid reflects that the beast never changes substantially. With the exception of the work RichardDonkin did on internationalising TWiki last year, I'd argue that they are not alpha's at all, just a progression of minor bug-fixes on a sluggish 15 month cycle.

I fear that unless the CoreTeamNominationDiscussions process gets real commitment in the form of positions taken by contributors, no real progress on the code is ever going to be made.

I'm starting to think that if I can't get the (mountain) TWiki to go to the cleaner-design of (Mohammed) CgiWiki, I'm I might give up, jump ship and help push CgiWiki to replicate the functionality found in TWiki.

-- MartinCleaver - 16 May 2003

Yes, I'm tempted too. I've got this stack of notes of the OO view of TWiki. It may be too much. The new Kwiki looks good even if the code is obscure.

-- AntonAylward - 16 May 2003

The implementation of Store.pm should be in four parts:

  1. Storage of the Topic body - Store::Topic
  2. Storage of the Meta data - Store::Meta
  3. Storage of the Preferences - Store::Pref
  4. Storage of the Access Control - Store:Access

Each storage should be uncoupled from each other and orthogonal in operation. In particular, as with regular file systems

  • It should be possible to alter the access control without altering the body
    • See chmod(1) under UNIX. The equivlent under VMS does not cause a nrew revision of the file to be created.
  • Altering the body should in no way affect access control
    • See all regular file systems
  • Revising the meta data (e.g. adding attachements) should not force a new revision of the body to be created.
    • The converse does not hold. Revising the body triggers and update to the meta data TOPICINFO

Each of these should be

  • In an AUTOLOAD form so that only the code that gets used gets compiled
  • In modules arranged so that the implementation methods can be over-ridden by plug-ins
    • The basic and accepted storage methods will be implemented by the "out of the box" methods.

-- AntonAylward - 16 May 2003

I note that saveNew (which seems to be the final deepest layer of Store.pm) does the check for whether the previous save was by the same user. Is there a way around this? In several situations I want a new revision to be saved regardless).

-- MartinCleaver - 06 Oct 2003

Maybe some others think, the following addition to the StoreDotPm is useful: Writing the DontNotify information into the logfile allow other applications (in my case a GlobalChanges shell script) to utilise it (in my case: not to show every change, only those which - according to the author - is important). Here is the diff.

-- OliverKrueger - 22 Oct 2003

CoreTeam - can this go in the core?

-- MartinCleaver - 22 Oct 2003

Follow-up in DontNotifyFlagInLogFile

-- PeterThoeny - 26 Oct 2003

The hidden text feature (see HiddenTextPluginDev) needs some assistence from StoreDotPm in order to prevent the hidden text to be compromised by users viewing the topic in raw mode. Diff is attached to HiddenTextPluginDev (Store.pm.HiddenTextPlugin.diff).

-- OliverKrueger - 05 Feb 2004

The previous version switched to viewauth if someone hit a page they couldn't see. This patch at least informs the user what they should do if they want to see content.

--- TWiki/Store.pm      2004-05-13 06:02:56.000000000 -0500
+++ TWiki/Store.pm.~1.88.~      2004-05-03 22:25:58.000000000 -0500
@@ -1325,7 +1325,7 @@

     unless( $viewAccessOK ) {
         # FIXME: TWiki::Func::readTopicText will break if the following text changes
-        $text = "No permission to read topic $theWeb.$theTopic\n";
+        $text = "No permission to read topic $theWeb.$theTopic - perhaps you need to log in?\n";
         # Could note inability to read so can divert to viewauth or similar
         $TWiki::readTopicPermissionFailed = "$TWiki::readTopicPermissionFailed $theWeb.$theTopic";
     }

  • commited smile thanks for the patch Martin -- SvenDowideit - 13 May 2004

-- MartinCleaver - 13 May 2004

readTopic() - if there is no meta data should you get "", undef, or an empty Meta object?

-- MartinCleaver - 03 Oct 2004

Ok, so you get a TWiki::Meta object. I am sorry I don't have access to update the docs.

-- MartinCleaver - 03 Oct 2004

Diagnosing readTemplate

It seemed that readTemplate was returning nothing, giving the error message that the file did not exist. This error message was wrong!

To work out readTemplate was doing, I added the following call. It is also a handy way to learn how our templating system works.

    # handle %TMPL:P{"..."}% recursively
    $result =~ s/%TMPL\:P{[\s\"]*(.*?)[\"\s]*}%/&handleTmplP($1)/geo;
    $result =~ s|^(( {3})+)|"\t" x (length($1)/3)|geom;  # leading spaces to tabs

+    diagnoseReadTemplate(\%templateVars, $result);
+    die;

    return $result;
}

And add this sub:

=pod

---++ diagnoseReadTemplate($templateVarsRef, $result)

Call this to illustrate the state of the readTemplate sub

=cut

sub diagnoseReadTemplate {
    my ($templateVarsRef, $result) = @_;
    print "Content-type: text/html\n\n";
    use Data::Dumper;

    $Data::Dumper::Pad = "                           ";
    print "<PRE>".Dumper($templateVarsRef)."</PRE><BR/><BR/><FONT COLOR=BLUE>".\
$result."</FONT><BR><BR>";

    unless ($result) {
        print "<FONT COLOR=RED>Result was empty!</FONT><BR>";
    }
}

This will show the hash that it builds, followed, in blue, by the invocation of an entry ($result) of the hash. When $result is empty your template will do nothing!

-- MartinCleaver - 16 Oct 2004

Edit | Attach | Watch | Print version | History: r23 < r22 < r21 < r20 < r19 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r23 - 2006-05-04 - SamHasler
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.