ImplementNewStrategy

Implement New Strategy

STEP ONE : Design and Implement a Re-factored Raquel Token Class

The purpose of the data members of a Raquel Token (object) is to provide a rational arrangement to hold all the data pertinent to a Raquel Token., despite the fact that the data to be held varies considerably in different tokens. The requirements are now well established, and a straightforward design of data members completed.
The function members required depend on the needs of the DBMS modules that access Raquel Tokens. There are a number of modules, and their needs are by no means completely established. Therefore a reasonable set of function members will be provided initially, but the set may be revised and/or extended as the DBMS develops.

The physical design of the new Raquel Token class is described in the following documents :

1. The Rationale of the RAQUEL Token Class Physical Design.
2. The RAQUEL Token Class - Data Members.
3. The RAQUEL Token Class - Function Members.
                           The function members that deal with name list parameters are more complex than those that deal with header fields and the pointers to the root nodes of various parse trees. The latter are relatively straightforward, and consist of fairly obvious GET and SET functions. The former are more complex, being tokenisers (albeit relatively straightforward tokenisers).

It is convenient to have one NameList member function to handle all the different kinds of name lists. It can handle all the general processing that applies to all name lists, e.g. general error checks. It is called DeriveNameLists and takes 2 arguments, one being the text of the name list parameter to the RAQUEL operator or assignment, and the other specifying which kind of name list the Raquel parameter text represents. Since for clarity it is also useful to have one member function for each kind of name list, DeriveNameLists calls the member function that is relevant to the particular kind of name function, to actually do the work.
The algorithms used for each kind of name list are described in the document Algorithms of "DeriveNameLists" Member Function. The algorithms are not as straightforward as at first sight they might be. This is because of the need to detect as many different kinds of error as possible in the parameter text. As it is useful to have a good set of test data to check for valid data and for a range of errors, the test data used is given in the document Test Inputs for NameLists Member Functions. The error numbers given in that document refer to the integer values of each member/enumerator of the enumerated type E_ERRORTYPES_RaquelToken, which is specifed in the file "ERRORTYPES-RaquelToken.h". (This file is in the repository under the path name RaquelDBMS/Branches/Refactor1/RAQUELTOKENClass).

The Raquel Token Class requires invariants, i.e. checks to ensure that a RAQUEL Token object is created with valid and consistent internal values.
Since consistency is included in the invariants, it creates the possibility that the invariants may also be useful to create valid token objects from only subsets of relevant input data, if the input data is an appropriate subset.
Moreover the patterns applied by the invariants are similar to the recognition patterns used by the Compactor. Some expression re-write algorithms may also find such patterns useful. Hence for simplicity the invariants are not part of the Raquel Token Class, but kept as a separate source referenced by the Raquel Token Class. The 'source' will in due course become a component of a Raquel DBMS library used for compiling the DBMS.

As the functionality of the DBMS is increased by adding more operators & assignments, the number of invariants must be increased to cope with them. For additional relational and DB schema operators & assignments, the additional invariants can be added to the DBMS library at the same time. However the scalar operators & assignments available depend on the scalar types currently 'plugged into' the DBMS. A different library arrangement will be needed for them, because each DBMS installation could have a diferent set of scalar types.

Besides invariants, there are two other sources referenced by the Raquel Token class, which will in due course become components of a DBMS library. They are :

1. The set of all possible errors that could arise when accessing a Raquel Token. They will eventually become a component of an 'Error' library that will be created, of all posible errors that could arise when using the DBMS.
2. The set of all possible types of 'NameList that can appear in a Raquel Token. They are potentially relevant to expression re-writer modules as well as the Compactor.

STEP TWO : Check the Parser, and Debug/Refine if Necessary

It is the Parser that sets up the pointers in a Raquel Token which link that token to its neighbour(s) in the parse tree created to represent the input statement. Thus the existing parser needs to be modified to handle the new Raquel Tokens. It can be checked for bugs at the same time.

STEP THREE : Revamp the Compactor

Significant changes must be made to the Compactor, in order to :

1. enable it to handle the new Raquel Token;
2. utilise the patterns in the invariants to help determine which Raquel Tokens are to be created;
3. fix the Compactor bug which causes it to incorporate literal relational values into the tokens of value assignments as parameters, instead of accepting those values as the right hand operands of the assignments.
4. ensure that the revised Compactor can recursively call the Tokeniser, itself, and the Parser, in order to generate the parse trees of expression parameters.

FURTHER STEPS : Decide on How Best to Implement the Execution of the New Parse Trees

In essence this concerns whether there is any short term merit in utilising the existing execution mechanism, or is it simpler to cannibalise it into the new DBMS architecture that will eventually be required anyway.

Return to [Home]
Return to [NewStrategy]