A tool exists for interactively browsing and updating LoganBerry databases. Think of the browser as a convenient way of performing LoganBerry commands. To run the browser, type:

The convention for naming databases is the same as that used by LoganBerryStub (see LoganBerryDoc.tioga); both local and remote databases may be browsed concurrently. The browser reads the database schema to discover what indices exist for the database. It then builds an input form in which values for the various attribute keys can be entered. These values are treated as patterns against which database entries are compared.

For example, [PCedar2.0]<LoganBerryTools>LoganBerrySampleDB.df is the schema for a sample database storing names and phone numbers. Typing "LoganBerryBrowser [PCedar2.0]<LoganBerryTools>LoganBerrySampleDB.df" (then clicking "AdminOps") produces a viewer that looks something like the following:

Feel free to run queries on this sample database by typing in patterns for names and/or phone numbers and then clicking on "Browse". If you want to update the database in any way, by clicking "Update", "Delete", "UnDelete", "BuildIndices", or "CompactLogs", please do a bringover first and then run the browser on your local copy of the database. In other words, type: Cd some-local-directory; Bringover -f [PCedar2.0]<LoganBerryTools>LoganBerrySampleDB.df; LoganBerryBrowser LoganBerrySampleDB.df.

The LoganBerry browser also allows one to browse several databases simultaneously; simply type in one or more database names as arguments to the LBBrowser command. The databases should have identical (or at least similar schemas). The user can select which databases to browse for each query. If more than one database is selected, then the results obtained from the multiple databases will be merged together in the output.

The browser has several areas or subviewers. At the very top is the caption indicating the name of the database being browsed. Right below this is a menu with one or two lines (the display of the second line is controlled by the "AdminOps" button). The function of each menu button is explained in the next section.

Below the menu is the input form. Each line of the input form allows the user to type in a pattern for a given attribute. For instance, the browser tool shown above has an input form with two attributes: "Name" and "Phone".

Preceding each attribute name on the input form is a choice button that allows the user to select what pattern matching is too be applied to the attribute value. Clicking on this choice button cycles through the various options (see the section on pattern-matching options below).

The last line of the input form is a text viewer with the label "other attributes:". For Browse and Delete operations, an optional boolean query can be type in this area; this query is ANDed to the patterns in the input form. See "Boolean Queries" in LoganQueryDoc.tioga for a description of the LoganBerry Query Language. For Update operations, this area can be used to type values for attributes that are not keys of the database.

Feedback concerning the execution of a query is printed to the right of the input form when the "Browse" button is clicked.

If the browser is being used to browse multiple databases, a collection of buttons, one for each database, will appear immediately below the menu and above the input form (these are not present in the browser above). A database is selected and deselected by clicking on the button with its name; a database is selected when the name in the button appears white on black. Any operation invoked via the browser is performed only on the set of selected databases.

Below the input form is another choice button that allows users to select on which attribute the output should be ordered. To speed up queries it is best to order the output on some attribute that has a well-specified pattern. Unless you really care about the order in which database entries are retrieved, leave the choice on "ANY" and the browser will attempt to optimize the execution of the query. The pattern-selection and order-by choice buttons comprise the details subviewer.

The history window optionally resides below the input form and details subviewer (it is not shown in the browser above). Whether or not it is currently displayed is governed by the "History" menu button. This area contains a list of the operations that have been executed in the past; these operations are given in a format that could be typed into a CommandTool as arguments to the LBQuery command to get identical results (except the database name is omitted). Clicking on one of these "history commands" fills in the input form with the values that previously existed and also sets the previous details. Thus, a query can be re-executed by selecting a line in the history window and clicking "Browse" again. The user is also free to change any of the values once they are refreshed.

At the bottom of the browser tool is the output area where the results of queries are displayed. This area is scrollable.

The LoganBerry Browser Tool displays the following menu buttons:

The second menu line offers the following buttons (intended mostly for advanced users):

Users can select the pattern matching that should be applied to various fields of a database entry using the choice buttons in the browser's input form. For each field in the input form, the user types in the desired pattern and type of pattern matching; these patterns are in turn compared against values obtained from the database. The types of pattern matching provided are those described above under "Pattern matching".

In addition, the user may select "DWIM". In this case, the browser attempts to deduce an appropriate filter type from the given pattern. The logic is as follows:

Warning: The "numrange", "daterange", and "date" pattern-matching filters are problematic since they assert that the attributes in the database are of a certain type other than simply ropes. The LoganBerry data management system treats all attribute values as ropes and does not enforce any constraints on the these values. If the browser encounters an attribute value that can not be converted to the type desired by the filter, then the entry is deemed to not match. Also, the "DWIM" option has the obvious problem that its semantics are not easy to predict or determine. For these reasons. "numrange", "daterange", "date", and "DWIM" are provided on an experimental basis only and should be used with caution.

As an example, suppose one wants to find all of the people in the LoganBerrySampleDB database whose phone number starts with "494". To fill in the input form, the user first clicks on "Name:", which places the input cursor next to this field so the user can type in a pattern for the names of the people to match; the user types "*". Next, the user next clicks on "Phone:" and types "494". Together, "Name: *" and "Phone: 494" specifies the desired query. At the point the browser looks like:

LoganBerryBrowser.mesa provides a programmer's interface that allows one to create a customized LoganBerry Browser; see the interface for details.

Several commands are available for invoking operations on a LoganBerry database from a CommandTool. These are described below. All of the commands, except for LoganBerryBrowser, can run in a "non-viewers" Cedar world, e.g. CedarTools.

All of the LoganBerry CommandTool commands have a similar syntax, "<cmdname> <dbname> <attributes>", a command name followed by a database name followed by a boolean query or zero or more attribute-pattern specifications. The database name may be for a remote database, see "Convention for naming remote databases", or may be the special name "#", which is a shorthand notation for the last database name given. An extension of ".df" is assumed for database names without explicit extensions.

An attribute-pattern specification is of the form: "<attribute-type>(<pattern>): <attribute-value>". The attribute value may be either a token or a rope literal. The currently supported types of patterns include "exact", "prefix", "wildcard", "re", and "soundex" (see above for a description of these patterns). The pattern, along with its surrounding parenthesis, is optional. A missing pattern defaults to "DWIM".