custom properties in stacks that aren't open

[Richard Gaskin]

Chris Sheffield wrote:

 >>>What happens if I refer to a custom property that is in a stack
 >>>that is not open?
 >>
 >> You can read any property of any object in any stack file at
 >> any time. If the stack is not open, it will be loaded into
 >> memory in order to access the property, but will not be
 >> "opened" per se (will not receive "openstack", opencard", etc.)
 >
 > So if I have a stack that's 50 MB containing binary data in custom
 > properties, will the whole stack get loaded into memory if I want
 > read the data from just one of those properties?

I believe that's the case.  Hopefully Tuviah can jump in here to clarify.

For this reason, when building large systems it may be useful to break 
data sets into multiple stack files.

Or if there are relatively few records each containing a fairly large 
amount of data you may just find it simpler to use the stack property to 
hold just the path to an external file for the data itself.

In fact, that even found its way into WebMerge: we encountered a few 
databases that fit that description (few records, large record sizes), 
and added a tag for doing what are basically a type of "include" which 
find a path in record data and copies the contents of that file where it 
would normally put the record data directly.

 > If that's the case, how do I close the stack to release that memory
 > if it's not really "open"?  Would I just issue a normal close stack
 > command?

A close command would only be needed if you had opened the stack, using 
either the open or go commands, or one of their equivalents that specify 
mode (modeless, modal, toplevel, palette).

Rev has a built-in property for this:  if you want to purge a stack from 
memory whenever you're done using it just set the stack's destroyStack 
property to true.

In spite of the needlessly alarming name the property is not destructive 
at all.  It's just destroying the memory-based copy of the stack, and 
does not affect the stack file.  I like to think of that property as 
"purgeStack".

This has an adverse affect on performance, however: the trade-off is the 
classic memory-vs-speed issue, played out here by needed to read the 
stack file from disk each time if the destroyStack is true.  If you can 
spare the RAM you might enjoy the zippy performance of keeping it in 
RAM, which you can likely do with 50MBs on most XP and OS X systems 
without needing to dip into VM.

-- 
  Richard Gaskin
  Fourth World Media Corporation
  ___________________________________________________
  Rev tools and more:  http://www.fourthworld.com/rev