1Boulder::Store(3) User Contributed Perl Documentation Boulder::Store(3)
2
6 Boulder::Store - Simple persistent storage for Stone tag/value objects
7
9 Boulder:Store;
10 my $store=new Boulder::Store('test.db',1);
12 my $s = new Stone (Name=>'george',
13 Age=>23,
14 Sex=>M,
15 Address=>{
16 Street=>'29 Rockland drive',
17 Town=>'Fort Washington',
18 ZIP=>'77777'
19 }
20 );
21 $store->put($s);
22 $store->put(new Stone(Name=>'fred',
23 Age=>30,
24 Sex=>M,
25 Address=>{
26 Street=>'19 Gravel Path',
27 Town=>'Bedrock',
28 ZIP=>'12345'},
29 Phone=>{
30 Day=>'111-1111',
31 Eve=>'222-2222'
32 }
33 ));
34 $store->put(new Stone(Name=>'andrew',
35 Age=>18,
36 Sex=>M));
37 $store->add_index('Name');
39 my $stone = $store->get(0);
41 print "name = ",$stone->Name;
42
44 Boulder::Store provides persistent storage for Boulder objects using a
45 simple DB_File implementation. To use it, you need to have Berkeley db
46 installed (also known as libdb), and the Perl DB_File module. See the
47 DB_File package for more details on obtaining Berkeley db if you do not
48 already have it.
49 Boulder::Store provides an unsophisticated query mechanism which takes
51 advantage of indexes that you specify. Despite its lack of sophistica‐
52 tion, the query system is often very helpful.
53
55 $store = Boulder::Store->new("database/path",$writable)
56 The new() method creates a new Boulder::Store object and associates
57 it with the database file provided in the first parameter (undef is
58 a valid pathname, in which case all methods work but the data isn't
59 stored). The second parameter should be a true value if you want
60 to open the database for writing. Otherwise it's opened read only.
61 Because the underlying storage implementation is not multi-user,
63 only one process can have the database for writing at a time. A
64 fcntl()-based locking mechanism is used to give a process that has
65 the database opened for writing exclusive access to the database.
66 This also prevents the database from being opened for reading while
67 another process is writing to it (this is a good thing). Multiple
68 simultaneous processes can open the database read only.
69 Physically the data is stored in a human-readable file with the
71 extension ".data".
72
74 $stone = $store->read_record(@taglist)
75 The semantics of this call are exactly the same as in Boul‐
76 der::Stream. Stones are returned in sequential order, starting
77 with the first record. In addition to their built-in tags, each
78 stone returned from this call has an additional tag called
79 "record_no". This is the zero-based record number of the stone in
80 the database. Use the reset() method to begin iterating from the
81 beginning of the database.
82 If called in an array context, read_record() returns a list of all
84 stones in the database that contains one or more of the provided
85 tags.
86 $stone = $store->write_record($stone [,$index])
88 This has the same semantics as Boulder::Stream. A stone is
89 appended to the end of the database. If successful, this call
90 returns the record number of the new entry. By providing an
91 optional second parameter, you can control where the stone is
92 entered. A positive numeric index will write the stone into the
93 database at that position. A value of -1 will use the Stone's
94 internal record number (if present) to determine where to place it.
95 $stone = $store->get($record_no)
97 This is random access to the database. Provide a record number and
98 this call will return the stone stored at that position.
99 $record_number = $store->put($stone,$record_no)
101 This is a random write to the database. Provide a record number
102 and this call stores the stone at the indicated position, replacing
103 whatever was there before.
104 If no record number is provided, this call will look for the pres‐
106 ence of a 'record_no' tag in the stone itself and put it back in
107 that position. This allows you to pull a stone out of the data‐
108 base, modify it, and then put it back in without worrying about its
109 record number. If no record is found in the stone, then the effect
110 is identical to write_record().
111 The record number of the inserted stone is returned from this call,
113 or -1 if an error occurred.
114 $store->delete($stone),Boulder::Store::delete($record_no)
116 These method calls delete a stone from the database. You can pro‐
117 vide either the record number or a stone containing the 'record_no'
118 tag. Warning: if the database is heavily indexed deletes can be
119 time-consuming as it requires the index to be brought back into
120 synch.
121 $record_count = $store->length()
123 This returns the length of the database, in records.
124 $store->reset()
126 This resets the database, nullifying any queries in effect, and
127 causing read_record() to begin fetching stones from the first
128 record.
129 $store->query(%query_array)
131 This creates a query on the database used for selecting stones in
132 read_record(). The query is an associative array. Three types of
133 keys/value pairs are allowed:
134 (1) $index=>$value
136 This instructs Boulder::Store to look for stones containing the
137 specified tags in which the tag's value (determined by the
138 Stone index() method) exactly matches the provided value.
139 Example:
140 $db->query('STS.left_primer.length'=>30);
142 Only the non-bracketed forms of the index string are allowed
144 (this is probably a bug...)
145 If the tag path was declared to be an index, then this search
147 will be fast. Otherwise Boulder::Store must iterate over every
148 record in the database.
149 (2) EVAL=>'expression'
151 This instructs Boulder::Store to look for stones in which the
152 provided expression evaluates to true. When the expression is
153 evaluated, the variable $s will be set to the current record's
154 stone. As a shortcut, you can use "<index.string>" as short‐
155 hand for "$s->index('index.string')".
156 (3) EVAL=>['expression1','expression2','expression3'...]
158 This lets you provide a whole bunch of expressions, and is
159 exactly equivalent to EVAL=>'(expression1) && (expression2) &&
160 (expression3)'.
161 You can mix query types in the parameter provided to query(). For
163 example, here's how to look up all stones in which the sex is male
164 and the age is greater than 30:
165 $db->query('sex'=>'M',EVAL=>'<age> > 30');
167 When a query is in effect, read_record() returns only Stones that
169 satisfy the query. In an array context, read_record() returns a
170 list of all Stones that satisfy the query. When no more satisfac‐
171 tory Stones are found, read_record() returns undef until a new
172 query is entered or reset() is called.
173 $store->add_index(@indices)
175 Declare one or more tag paths to be a part of a fast index.
176 read_record() will take advantage of this record when processing
177 queries. For example:
178 $db->add_index('age','sex','person.pets');
180 You can add indexes any time you like, when the database is first
182 created or later. There is a trade off: write_record(), put(),
183 and other data-modifying calls will become slower as more indexes
184 are added.
185 The index is stored in an external file with the extension
187 ".index". An index file is created even if you haven't indexed any
188 tags.
189 $store->reindex_all()
191 Call this if the index gets screwed up (or lost). It rebuilds it
192 from scratch.
193
195 Boulder::Store makes heavy use of the flock() call in order to avoid
196 corruption of DB_File databases when multiple processes try to write
197 simultaneously. flock() may not work correctly across NFS mounts, par‐
198 ticularly on Linux machines that are not running the rpc.lockd daemon.
199 Please confirm that your flock() works across NFS before attempting to
200 use Boulder::Store. If the store.t test hangs during testing, this is
201 the likely culprit.
202
204 Lincoln D. Stein <lstein@cshl.org>, Cold Spring Harbor Laboratory, Cold
205 Spring Harbor, NY. This module can be used and distributed on the same
206 terms as Perl itself.
207
209 Boulder, Boulder::Stream, Stone
210perl v5.8.8 2000-06-08 Boulder::Store(3)