Class for executing queries and updates. More...
#include <QueryEngine.h>
Public Member Functions | |
ReturnCode | select (int nAttributes, const RelationAttribute attributes[], int nRelations, const char *relations[], int nConditions, const Condition conditions[]) |
Executes a SQL "select-from-where" query. | |
ReturnCode | insert (const char *relName, int nValues, const TypedValue values[]) |
Executes a SQL "insert into" command. | |
ReturnCode | remove (const char *relName, int nConditions, const Condition conditions[]) |
Executes a SQL "delete from" command. | |
ReturnCode | update (const char *relName, const RelationAttribute *left, const AttributeOrValue *right, int nConditions, const Condition conditions[]) |
Executes a SQL "update" command. | |
Static Public Member Functions | |
static QueryEngine * | getInstance () |
Gets the singleton QueryEngine instance. |
Class for executing queries and updates.
The QueryEngine class is used to execute SQL query and update commands in DavisDB. It contains public methods corresponding to the SQL "select," "insert," "delete," and "update" statements supported by the DavisDB command- line shell. Like SystemManager, it is invoked by the command-line shell as a backend component to actually carry out these commands. QueryEngine is a singleton class; a reference to the singleton object is obtained by calling QueryEngine::getInstance.
ReturnCode QueryEngine::insert | ( | const char * | relName, | |
int | nValues, | |||
const TypedValue | values[] | |||
) |
Executes a SQL "insert into" command.
relName | The name of the target relation | |
nValues | The number of values to insert | |
TypedValue | The list of values to insert |
Executes a SQL "insert" command issued via the DavisDB command-line shell by inserting the specified tuple into the specified relation. Returns RC_OK on success, and other RC error codes otherwise. Your implementation should check that the command as issued typechecks against the database schema and return a non-zero RC error code if it does not.
To provide feedback to the user, this method should also print the inserted tuple on the console (using the SystemPrinter class).
ReturnCode QueryEngine::remove | ( | const char * | relName, | |
int | nConditions, | |||
const Condition | conditions[] | |||
) |
Executes a SQL "delete from" command.
relName | The name of the target relation | |
nConditions | The number of "where" conditions | |
conditions | The list of "where" conditions |
Executes a SQL "delete from" command by deleting any tuples matching the specified conditions from the specified relation. The list of conditions may be empty (nConditions == 0), in which case all tuples should be deleted from the relation. Returns RC_OK on success, and other RC error codes otherwise. Your implementation should check that the command as issued typechecks against the database schema and return a non-zero RC error code if it does not.
To provide feedback to the user, this method should also print the deleted tuples on the console (using the SystemPrinter class).
If the user has specified "set queryplans=on;" via the DavisDB shell, then before executing the deletion, your implementation should pretty-print the tree-structured plan to the console. For full credit in this component of the project, the TA must be able to easily understand your deletion execution strategy based upon the pretty-printed plan information.
ReturnCode QueryEngine::select | ( | int | nAttributes, | |
const RelationAttribute | attributes[], | |||
int | nRelations, | |||
const char * | relations[], | |||
int | nConditions, | |||
const Condition | conditions[] | |||
) |
Executes a SQL "select-from-where" query.
nAttributes | The number of attributes in the "select" clause | |
attributes | The list of attributes in the "select" clause | |
nRelations | The number of relations in the "from" clause | |
relations | The list of relation names in the "from" clause | |
nConditions | The number of conditions in the "where" clause | |
conditions | The list of conditions in the "where" clause |
Executes a SQL "select-from-where" query issued via the DavisDB command- line shell and prints the result of the query to the console via calls to SystemPrinter. Your implementation should check that the query typechecks with respect to the database schema and return a non-zero RC error code if it does not. Returns RC_OK on success, and other RC error codes otherwise. Parameters nAttributes and nRelations are guaranteed to be non-zero, but nConditions may be zero (for queries with no "where" clause).
If the user has specified "set queryplans=on;" via the DavisDB shell, then before executing the query, your implementation should pretty-print the tree-structured query plan to the console. For full credit in this component of the project, the TA must be able to easily understand your query execution strategy based upon the pretty-printed plan information.
ReturnCode QueryEngine::update | ( | const char * | relName, | |
const RelationAttribute * | left, | |||
const AttributeOrValue * | right, | |||
int | nConditions, | |||
const Condition | conditions[] | |||
) |
Executes a SQL "update" command.
relName | The name of the target relation | |
left | The attribute to be updated | |
right | The attribute name or constant whose value should replace that of left | |
nConditions | The number of conditions | |
conditions | The list of conditions |
Executes a SQL "update" command by replacing the value of the left attribute in any tuple matching the conditions with the value of the right attribute or constant. Returns RC_OK on success, and other RC error codes otherwise. Your implementation should check that the command as issued typechecks against the database schema and return a non-zero RC error code if it does not.
To provide feedback to the user, this method should also print the updated tuples on the console (using the SystemPrinter class).
If the user has specified "set queryplans=on;" via the DavisDB shell, then before executing the update, your implementation should pretty-print the tree-structured query plan to the console. For full credit in this component of the project, the TA must be able to easily understand your update execution strategy based upon the pretty-printed plan information.