3.3 Example

The fragment TextHashTable.bet defines a pattern TextHashTable whose instances are to be made persistent.

Program 1: TextHashTable.bet

ORIGIN '~beta/basiclib/betaenv'; INCLUDE '~beta/containers/hashTable'; INCLUDE '~beta/basiclib/texthash'; ---lib: attributes--- TextHashTable: hashTable (# honey: @honeyman; init::< (# do honey.init #); element::< Text; rangeInitial:: (# do 300 -> value #); hashfunction::< (# do e[]->honey.hash -> value #); #);

The fragment fooprod.bet describes a program that creates a new persistent store and saves some persistent objects:

Program 2: fooprod.bet

ORIGIN '~beta/basiclib/betaenv'; INCLUDE '~beta/persistentstore/persistentstore'; INCLUDE 'TextHashTable'; --PROGRAM:descriptor-- (# PS: @persistentstore; H: ^TextHashTable; do (* Create the persistent store *) PS.init; 'myStore' -> PS.create; (* Create a table of objects. *) &TextHashTable[] -> H[]; H.init; 'first' -> H.insert; 'second' -> H.insert; 'third' -> H.insert; (* Make the table a persistent root. *) (H[],'TextTable') -> PS.put; (* Checkpoint and close the store. *) PS.close #)

The fragment foocons.bet describes a program that makes use of some persistent objects:

Program 3: foocons.bet

ORIGIN '~beta/basiclib/betaenv'; INCLUDE '~beta/persistentstore/persistentstore'; INCLUDE 'TextHashTable'; --PROGRAM:descriptor-- (# PS: @persistentstore; H: ^TextHashTable; T: ^Text; do PS.init; 'myStore'-> PS.openWrite; ('TextTable', TextHashTable## ) -> PS.get -> H[]; 'fourth' -> H.insert; H.scan (# do current[] -> putLine #); PS.close #)

Other example usages of the persistent store may be found in the directory BETALIB/demo/persistentstore. These demo programs, part of the Mjølner System, are listed below:

• build.bet and oobench.bet implements a simple benchmark of the persistense framework. Run build to build the test store, then run oobench to time vaious operations.
• index.bet is a file indexer using a tree-like datastructure. The search function finds all words beginning with a given character.
• crossStoreDemo.bet demonstrates using multiple persistent stores from one program.

Example of usages of the OLD persistent store may be found in the directory BETALIB/demo/persistentstore/OLD. These demo programs, part of the Mjølner System, are listed below:

• largeWrite.bet, largeRead.bet work as described above.
• showregister.bet is an example of how to save a simple register in a persistent store. The register is built in a simple interaction with the user and finally saved. Later runs of showregister may read the saved register and perform simple queries. Finally the persistent store containing the register may be deleted.
• hashdemo.bet builds a simple hashtable of text strings. For each run of the program, an extra element is inserted into the table. If the persistent store does not already exist, it is created, and a new hashtable instance is made a persistent root. If the store already exists, the table is read, an extra element inserted, and the table scanned before the persistentstore is closed, implicitly implying a checkpoint operation.
• structdemo.bet is similar to hashdemo.bet, but illustrates the possibility of saving pattern variables in a persistent store. Pattern variables cannot become persistent roots, but as demonstrated by structdemo.bet, they are allowed in the transitive closure of a persistent root.
• special.bet is an example of how to limit the part of the transitive closure of persistents roots saved along during checkpoint operations. By registering the program pattern as a special object, even objects with origin ^[2] in the program object can be made persistent roots. Furthermore, by registering the IntegerObject pattern as a runtime type, references to all instances of IntegerObject are saved as NONE references. Runtime types and special objects are described in detail in the next section.
• crossstore.bet illustrates the handling of references between objects in different persistent stores. The same element is put into two different hashtables that in turn are saved in two different persistent stores. When one table is then fetched from its persistent store, it becomes necessary to open the persistentstore containing the shared element. The example shows how this must be taken care of by the programmer using the persistent store. The shared element is modified through the second table. On second run of the crossstore executable this modification is made visible through a scan of the first table. Details on references between different persistent stores are described in the following section.