Problems were found in 3 specific areas :-
The programming team who produced the PoC prototype had written documentation that provided an overview of the prototype, and the program code itself was commented. However what was lacking was 'in-between' documentation that described the rationale for the object-oriented design to implement the specified architecture, and also descriptions of the algorithms used. Furthermore it was found to be difficult to relate the code produced with the published Logical Architecture of the RAQUEL DBMS.
For completeness, unit tests were carried out on the Tokeniser to ensure it could cope with the 4 procedures. The tests demonstrated that it could. However several generally-applicable bugs were found and fixed - see the Bugs-DBMS ticket entitled Debugging the Tokeniser for details. The debugged version of the Tokeniser has been incorporated into the CInputStack class - see the RaquelDBMS/Branches/AddMeta/src section of the repository.
The Compactor is fairly complex. Isolating it from the Input Stack so that it can be developed and unit tested before putting the developed version into the Input Stack is extremely difficult. The Extending the Compactor to Handle [IncrementOne] document describes the way it needs to be done. Considerable complexity is involved.
The Parser essentially works as specified, but there appears to be a slight deviation in the algorithm implemented from the algorithm specified, which explains a quirk in the examples appearing in the PoC prototype documentation. Therefore the Parser needs to be tested and debugged.
A fundamental difference exists between the implementation of the 'Increment One' functionality and the implementation of the PoC prototype functionality.
Implementing PoC functionality was achieved by having an algorithm for each operator/assignment (expressed in C++ as a function) that is applied to the operand(s) of the operator/assignment to return a result. Thus to execute a parse tree composed entirely of such operators/assignments, the tree can be traversed upwards from its leaf nodes by applying the algorithms of the process nodes to their data nodes, the return values becoming the data nodes of the process nodes higher up in the tree, and so on till the root node is reached. Data nodes will be either literal values, held within the node itself, or variables whose values are taken from the DB.
The approach is straightforward was used in the Poc prototype. The objects which form the parse tree's nodes are large, containing not only the Raquel Token data but also the execution methods (i.e. algorithms) of the Raquel process tokens. Nevertheless such objects are feasible, and indeed appropriate in that the methods of the process tokens are conveniently accessible.
By contrast, implementing 'Increment One' functionality requires manipulation of the Meta DB, entirely in the case of the Meta operator, and in the case of the 3 assignments together with manipulation of the DB.
In consequence, to execute an 'Increment One' operator/assignment requires that each one has an algorithm that generates one or more parse trees, the precise nature and number of those parse trees being determined by the specifics of the invocation of the operator/assignment. Those parse trees are then executed in order to execute the invocation of the operator/assignment. The parse trees are expressed in terms of PoC operators/assignments, they can be immediately executed without further ado.
A single parse tree is generated to execute the Meta operator. It is executed on the Meta DB.
But for all 3 assignments, there can be multiple parse trees which have to be executed in parallel (conceptually). In general some of the parse trees are executed on the Meta DB and some on the DB.
See the 'IncrementOne : Operators and Assignments' section, pages 4 - 6, of Implementation Notes for details.
It is not clear how or even whether it is feasible to implement the 3 assignments within the PoC architecture.
Return to [Home]