Tags:
create new tag
view all tags

SetGetPluginDev Discussion: Page for developer collaboration, enhancement requests, patches and improved versions on SetGetPlugin contributed by the TWikiCommunity.
• Please let us know what you think of this extension.
• For support, check the existing questions, or ask a new support question in the Support web!
• Please file bug reports in the SetGetPlugin bug database.

SetGetPlugin Feedback and Development

-- PeterThoeny - 2010-10-17

Idea for enhancement: Add a new syntax to set a variable structure in JSON syntax (http://www.json.org/), using JavaScript syntax to set the variable. Examples:

JSON array:
%SET{ weekdays = [ "Mon", "Tue", "Wed", "Thu", "Fri" ] }%
%GET{ weekdays }% -- returns raw array of weekdays: [ 'Mon', 'Tue', 'Wed', 'Thu', 'Fri' ]
%GET{ weekdays[0] }% -- returns first item of weekdays: Mon

JSON object:
%SET{ users = {
     "tom":   "Thomas",
     "dick":  "Richard",
     "larry": "Lawrence",
   }
}%
%GET{ users }% -- returns complete hash, formatted in JSON
%GET{ users.tom }% -- returns hash element: Thomas

-- PeterThoeny - 2010-10-17

I think this plugin is going to save my life, so I'm going to use the hell out of this (with remember), and that makes me worried about two things:

1) locking either _savePersistentVar or the dat file during the write. I'm not smart enough to know the best way to do that, especially when there are (potentially) multiple processes running simultaneously

2) That being said, I would want to change this on the SET to only write if the variable is new or changed.

I'm going to be creating a lot of variables, and doing a ton of SETs, but the (vast) majority of the time the variable values will not change, which is why (2) is so important to me.

I'm happy to work on this, but I need guidance, particularly on (1). I think I can handle (2).

Merci!

-- AaronLWalker - 2011-09-07

I think this will save me a lot of grief, but I don't know how to handle the locking so I don't get bit:

Inside sub VarSET

    my $remember = $params->{remember} || 0;
    if( $remember && ! ( $remember =~ /^off$/i ) ) {
        if( defined $this->{PersistentVars}{$name} && $value eq $this->{PersistentVars}{$name} ) {
                TWiki::Func::writeDebug( "-   eliding set persistent -> $value" ) if $this->{Debug};
        } else {
                TWiki::Func::writeDebug( "-   set persistent -> $value" ) if $this->{Debug};
                $this->_savePersistentVar( $name, $value );
        }
    } else {
        TWiki::Func::writeDebug( "-   set volatile -> $value" ) if $this->{Debug};
        $this->{VolatileVars}{$name} = $value;
    }

-- AaronLWalker - 2011-09-07

Thanks Aaron for working on this!

For 1, use blocking shared file locking for reading, and exclusive locking for writing. See http://perldoc.perl.org/functions/flock.html, http://www.perlmonks.org/?node_id=7058, http://perl.plover.com/yak/flock/ and http://perldoc.perl.org/perlopentut.html#File-Locking.

-- PeterThoeny - 2011-09-07

One thing I'd like to do (if I find the time and it's not too disruptive) is to have the option to specify the backend file name. Have a db="..." argument, and have the default be persistentvar.dat (or whatever it is). It would make this a lot more flexible, reduce the chance of collisions, and allow pseudo-versioning of this stuff.

-- AaronLWalker - 2012-01-06

I can see the need for different namespaces for storing the variables. As for naming, instead of db="..." as seen from the implementer, how about a namespace="..." (or the like) as seen from the user?

-- PeterThoeny - 2012-01-07

I have no problem with any naming smile I was suggesting having separate files, and I hear you as saying different namespaces. We could do both. Do you see a value in having both? It would, at the least, increase flexibility. And, if desired, what naming would you prefer (for the "file" choice)?

-- AaronLWalker - 2012-01-16

I think we are talking about the same thing functionality-wise. I am just elaborating on the naming. User-centric names would be namespace or group to group variables into "buckets". This is less developer-centric than specifying name of file (the underlining technology could change to a database of object store in the future). My 2c.

-- PeterThoeny - 2012-01-16

There is one annoying problem with this great plugin, when you have a few dozen of defined variables and you change few of them, after they have been cached, some of them does not update to the new modified value. They simply retain the initial defined (calc.) value. The only workaround i've found to fix this was to rename the "corrupted" variables to get the new values.

Any suggestion to fix this problem? Regards.

-- AlinGramescu - 2012-03-08

Alin, this should not happen. Could you please file a bug at TWikibug:SetGetPlugin ? Please state details of environment, such as if you use mod_perl or another cgi accelerator. Specify also an example to reproduce the issue.

-- PeterThoeny - 2012-03-08

I was hoping that SET and GET would provide a simple way around the "variable settings don;t pwork in INCLUDEd topics" problem. But it doesn;t seem to.

Am I missing something?

As always, I want to set a variable in topic A, INCLUDE A (and the Set code) into B and use the variable in B.

-- Vicki Brown - 2014-03-20

The SET and GET work with the normal inside-out / left-to-right evaluation order like other TWiki Variables that register their tags. So, yes, you can set a variable before include & use that in the include, and set/modify a variable in an included topic and use it after that include.

-- Peter Thoeny - 2014-03-20

The latest version in the SVN repository renders %GET{"NotYetDefined"}% into %GET{"NotYetDefined"}%. Is it intended? Previously, when an undefined value was GETed, a null string was returned.

-- Hideyo Imazu - 2015-03-12

Not intended. I'll check.

-- Peter Thoeny - 2015-03-12

Thank you Hideyo-san, this is now fixed in SVN trunk. Docs and some code pending of JSON enhancements.

-- Peter Thoeny - 2015-03-26

I just posted a new SetGetPlugin version, now with support for JSON objects. A JSON path can be applied to get and set sub-parts of a JSON object. Test case examples at TWikibug:Item7611. Enjoy!

-- Peter Thoeny - 2015-03-28

I just updated the SetGetPlugin. Now it is possible to specify a store (or namespace) for the persistent variables. Mainly intended if you have a big dataset you want to save persistently, but you do not want to pollute the primary namespace. This is tracked at TWikibug:Item7635. Enjoy!

-- Peter Thoeny - 2015-04-08

Additional enhancements done:

  • Use file locking for persistent store files to prevent corruption of store on simultaneous updates
  • SETGETDUMP can now dump volatile variables
  • Init variables at plugin init time (was not the case in a mod_perl environment)

-- Peter Thoeny - 2015-04-09

Edit | Attach | Watch | Print version | History: r20 < r19 < r18 < r17 < r16 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r20 - 2015-04-09 - PeterThoeny
 
  • 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-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.