Record and Record Store Management
The Record Management System (RMS) is built around the RecordStoreclass, which is accompanied by helper classes (RecordStore-related exceptions, for example) and interfaces (which may be implemented to ease browsing through the store). It provides a simple record-oriented database. To get an idea of what the term record means, think of addresses or diary- or appointment-like entries. Though each entry contains unique information (for example, the name, address, date of birth, and telephone and fax numbers of exactly one person), its general structure is identical. Each record includes space for the same set of fields. So related information (consisting of the fields I mentioned) is grouped into chunks called records.
MIDlets read and write records through a unique identifier called the recordId. When a new record is added to the record store, it is assigned a new recordId, which stays the same as long as the record store exists. MIDlets may access records in any order, but have to read or write whole records. This implies that random access to the contents of the database is not on a byte level, but rather on a record level. recordIds range from 1 to n, where n is the total number of records in a store.
What information is stored in a record is not important to the RMS. It even does not know about how records are organized. It sees them as arrays of bytes, so the physical layout of records and their size may vary–the MIDlet is responsible for handling this correctly. The only thing important to the RMS is the recordId, which acts as a primary key. Figure 1 illustrates the concept of records in a record store.
