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
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