LoganBerryToolsDoc.tioga
Doug Terry, April 23, 1986 5:15:31 pm PST
LOGANBERRYTOOLS
CEDAR 6.0 — FOR INTERNAL XEROX USE ONLY
LoganBerry Tools
Doug Terry
© Copyright 1985 Xerox Corporation. All rights reserved.
Abstract: LoganBerry is a simple facility for managing databases. LoganBerry tools include LoganBerryStub, a package that handles interactions with local and/or remote LoganBerry servers, LoganQuery, which allows complex queries to be formulated such as those involving filters and mergers, and the LoganBerry Browser, which permits one to browse a LoganBerry database interactively.
Created by: Doug Terry
Maintained by: Doug Terry <Terry.pa>
Keywords: database, servers, RPC, queries, browsing
XEROX   Xerox Corporation
    Palo Alto Research Center
    3333 Coyote Hill Road
    Palo Alto, California 94304

For Internal Xerox Use Only
LoganBerryStub
LoganBerryStub provides easy access to local or remote LoganBerry database servers. It attempts to hide any RPC details. That is, it (1) catches RPC failures and attempts to either recover or turn them into LoganBerry errors, (2) imports RPC interfaces from multiple servers on demand, (3) uses secure RPC conversations, and (4) tries to keep LoganBerry databases open.
The interface is identical to LoganBerry.mesa. Any LoganBerry application should be able to change its imports statement to:
IMPORTS LoganBerry: LoganBerryStub;
and everything should continue to work. The major difference is that the application can now access remote databases as well as local ones. The server portion of the database name is taken to be the instance under which the remote LoganBerry server has exported its LoganBerry interface. For example,
LoganBerryStub.Open["/Strowger.lark//Database.schema"];
attempts to set up an RPC connection with Strowger.lark and open a database named "///Database.schema" on that server.
LoganQuery
LoganQuery allows more complicated queries to be performed on a LoganBerry database than the simple retrievals provided by the LoganBerry interface. Database queries of various classes can be registered; retrieval operations are class-specific. For instance, the $Filter class returns database entries that match a particular pattern, while the $Merger class merges the entries returned by two independent queries. Filters can be cascaded to perform multiple-attribute queries. The predefined $Simple class permits operations identical to those provided by LoganBerry. Clients are free to create their own class of queries.
LoganBerry Browser
Basics
A tool exists for interactively browsing LoganBerry databases. Currently, the browser tool does not allow interactive updates to be performed. So databases must be created using either the LoganBerry programmer's interface or the editor to create log files. To run the browser, type:
Bringover -p /Cedar/CedarChest®/Top/LoganBerry.df
LoganBerryBrowser some-database-schema-name
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.
User interface
The LoganBerry Browser Tool displays the following menu buttons:
STOP!: terminates a currently executing database query.
Browse: initiates a database query to retrieve all entries matching the input form. That is all database entries whose attribute values match the correponding pattern in the input form (according to some criteria, see below) are displayed in the output viewer of the browser. Various types of pattern matching are supported:
Details: toggles whether or not the details that govern how a query is performed are displayed.
History: toggles whether or not the history of part queries is displayed. This is not currently implemented.
AdminOps: displays (or hides) a second menu line that contains buttons for performing administrative operations on the database, such as Open, Close, BuildIndices, or CompactLogs.
The details viewer include a choice button for each field of the input form specifying the kind of pattern matching that applies to that field:
exact: values must match exactly;
prefix: the pattern must be a prefix of the database entry's attribute value;
wildcard: the pattern may contain zero or more wildcards (the character "*") that match anything;
regular expression: the pattern is taken to be a regular expression as defined in RegularExpressionDoc.tioga;
soundex: the form value's Soundex code is compared with that of a database entry's attribute value, i.e. values match in they "sound" alike; for instance, Johnson, Jansen, and Johansen have identical Soundex codes.
A choice button also exists that allows users to select on which attribute the output should be ordered. Fine point: to speed up queries it is best to order the output on some attribute that has a well-specified pattern.