Saving Changes in a Standalone

[Richard Gaskin]

stephen barncard wrote:

 > Remember a stack can both be a visible window with objects and
 > a holder for scripts, it can also be a very efficient and
 > addressable data container.
 >
 > The stack one compiles as an app can call other stacks that are not
 > compiled. The best of both worlds.

Stack files are my favorite means of storage.  These days I only use 
text files for ultra-large repositories too big to be loaded into RAM 
(with an index you'd be surprised how fast Rev can get in and out of 
such things with seek).  But for almost everything else I use stacks.

With stacks you can use custom props, which are by far the most 
efficient means of using persistent arrays in Rev.  RevTalk provides the 
arrayEncode and arrayDecode functions which can be used for similar 
purposes, but the overhead of translating arrays with those functions is 
many times more costly than just opening a stack which has the data in 
custom props.

I've tested with more than 100,000 custom props on stack files up to 
100MB, and as long as you have the RAM it works great.  Smaller files 
(50MB or less) work amazingly fast in most memory configurations, even 
with similarly large numbers of props.

Since custom props can be separated into property sets, you get two 
levels of hierarchy supported with amazingly efficient access speed.

While it's possible to store arrays in props to extend that hierarchy 
further, the speed is lost as those need to go through the internal 
equivalent of arrayDecode to be accessed.

But as long as you stick with property sets and properties you get a 
robust data store that's hard to beat for efficiency.  If you need a 
deeper hierarchy you can add objects there and use those props as well. 
  That's one of the other things I like about stack files as data 
stores:  you can store either text or binary data, or even native 
objects, mixing and matching for nearly every need.

Extra bonus points:  unlike a text file, with stacks you get an 
automatic backup made during save, so if you have a power outage or 
other interruption during save at least you'll have a copy of your last 
saved file, found in the same directory with the same name preceded with 
"~".

Tip:  The engine currently doesn't prevent you from using property names 
longer than 255 chars, but as noted in the Limits section of the docs 
such names are not allowed.  If you attempt to use a longer name it will 
corrupt your stack file - see:
<http://quality.runrev.com/qacenter/show_bug.cgi?id=8840>

Just stick to the 255-char limit and you're good to go.  Short strings 
and of course numeric keys work great.

--
  Richard Gaskin
  Fourth World
  Rev training and consulting: http://www.fourthworld.com
  Webzine for Rev developers: http://www.revjournal.com
  revJournal blog: http://revjournal.com/blog.irv