Rev Stacks for "tiny" read only backend web dBases

J. Landman Gay jacque at
Fri Feb 11 18:02:53 EST 2005

On 2/11/05 1:45 PM, Sivakatirswami wrote:

> For a small amount of data to be delivered on the web e.g. 1000 records 
> or less; in this case, word definitions of a glossary. where the record 
> has only two pieces of data
> --word
> -- definition, 
>  am wondering if a back end revolution stack can serve us?

I would think so. Even if you just use "find" to locate the words, it 
wouldn't be too bad (though the "find" command isn't the fastest thing 
in the world.) The fastest way to locate a card is by ID though, so you 
might want to create a lookup table instead. Before you publish the 
stack, run a handler that walks through the cards and stores the word 
and the card ID in a list somewhere. Then have the CGI get the lookup 
table, extract the ID, and grab the definition from that card.

Which actually means that someone else's suggestion of just using a text 
file might work just as well, though maybe a little less esthetic for 
data entry.

> Since input will be by a single admin individual, access would be read 
> only. It's so simple, I'm not sure we need a macho PostGreSQL dbase for 
> this and a Rev Stack would be so easy-portable. I can have someone 
> working on a stack on his own machine... then just move it to the server 
> how efficient is that... very...

Right. Very easy.

> The question would be: are there any read access concurrency issues in 
> such a web app context?

Not if the file is only being read. It can be opened multiple times by 
any number of instances of the engine.

> Anyone else doing this? what's your experience?
>  if a cgi calls
> "start using stack "../html/books/master_lexicon.rev"
> ... does that mean another person hitting the same CGI within 
> milliseconds will have a problem?

I have a CGI on my site that does this. There hasn't been any problem, 
as long as the files are read-only.

Jacqueline Landman Gay         |     jacque at
HyperActive Software           |

More information about the Use-livecode mailing list