save data in custom properties in a stack- or a text file?

[Richard Gaskin]

Josh Mellicker wrote:

> I know stacks are a nice way to save a lot of data because it can be  
> organized by custom property and custom property set.
> 
> But what about a simple list of data consisting of name, URL, and a  
> couple other fields, that needs to be downloaded from a server- would  
> you save the data in:
> 
> A. a stack in custom properties?
> B. Or a text file?
> 
> The information in this case will never get more complicated, though  
> is remotely possible a data field or two might be added in the  
> future. But the data will never evolve to be complex, it will always  
> merely be a list of files.
> 
> 
> Here is my comparison:
> 
> writing to/reading from: code must be written for both, text file a  
> little easier

Depends on what you're writing.  If you're just writing a single 
sequential list than dumping it to a file would be simple enough.  But 
if you need to access specific elements of that data, it's hard to beat 
the convenient flexibility and performance of array syntax to get custom 
prop elements.

> entering/reading data manually: text file way easier

What is "manually" in this context?  What other processes in the 
workflow require "manual" editing?

> encrypting: a tie
> 
> adding data "fields": a tie, easy in either (you must think ahead)

Maybe, maybe not.  Again, it depends on the specifics of the 
implementation.  Adding a column to a list is easy enough, and using 
linked-listed to attach even large elements to property arrays can be 
easy enough, more efficient with large data, and possibly more flexible.

> possible data corruption: a tie

Maybe, but consider this:

If you parse your own file yourself, you're responsible for defining the 
format and the accessors which will use that format, and must test your 
invention thoroughly.

But the custom property mechanism is already in the engine, already 
field-tested for more than a decade, and in all that time I've only even 
heard about three cases of true file corruption, and only seen one of 
those firsthand myself. Ten years is a long time.

Also, with stack files you get an automatic temporary backup whenever 
the save command is issued:  the last saved copy of the stack file is 
written to a temp file preceeded with a tilde (e.g., "mystack.rev" 
becomes "~mystack.rev"), then the new stack file is written fresh from 
RAM contents, and only when the integrity of the completely fresh file 
has been checked is that temp file deleted.

So among other things this means that if your using has a power outage 
during a save, or any other unexpected interruption, the engine's 
handling of stack files automatically gives you a safety that's been 
proven in real-world work for many years.  You'd have to write that 
yourself if you wanted to provide similar protection.

Another plus for stack files:

With stack files you can add other lists, tables, metadata, even 
hierarchical data at any time without changing the accessors for your 
original data set. This inherent zero-cost extensibility is one of many 
reasons I've been migrating most of the apps I manage from custom 
formats to stack file formats.

-- 
  Richard Gaskin
  Managing Editor, revJournal
  _______________________________________________________
  Rev tips, tutorials and more: http://www.revJournal.com