Struct stellar_sql::sql::worker::SQL

pub struct SQL {
    pub user: User,
    pub database: Database,
    pub querydata: QueryData,
    pub result_json: String,
}

Fields

user: User

database: Database

querydata: QueryData

result_json: String

Methods

impl SQL

pub fn new(username: &str) -> Result<SQL, SQLError>

pub fn create_database(&mut self, db_name: &str) -> Result<(), SQLError>

pub fn load_database(&mut self, db_name: &str) -> Result<(), SQLError>

Load a database

pub fn drop_database(&mut self, db_name: &str) -> Result<(), SQLError>

Drop the database

pub fn create_table(&mut self, table: &Table) -> Result<(), SQLError>

Load the database and create a new table

pub fn drop_table(&mut self, table_name: &str) -> Result<(), SQLError>

Drop the table

pub fn insert_into_table(
    &mut self,
    table_name: &str,
    attrs: Vec<String>,
    rows: Vec<Vec<String>>
) -> Result<(), SQLError>

Insert new rows into the table

pub fn select(&mut self) -> Result<(), SQLError>

Handle the select query

Syntax:

(8)  SELECT (9) DISTINCT (11) TOP <top_specification> <select_list>
(1)  FROM <left_table>
(3)       <join_type> JOIN <right_table>
(2)       ON <join_condition>
(4)  WHERE <where_condition>
(5)  GROUP BY <group_by_list>
(6)  WITH {CUBE | ROLLUP}
(7)  HAVING <having_condition>
(10) ORDER BY <order_by_list>

Process:

0. Semantic check: tables exists, fields exists, predicate is valid.
1. FROM: If there is no where clause or join-on clause join, the virtual table VT3 is that table, and go step 4. Else, it is a join. A Cartesian product (cross join) is performed between each two tables, and as a result:
   • 1-1. If the number of tables between FROM and JOIN are more than one, it is a where-clause inner join. Cross join tables and generate virtual table VT3. Go step 4.
   • 1-2. Otherwise, there should be only a table between FROM and JOIN, and there must be JOIN ON clause(s). If the first JOIN ON, cross join FROM and JOIN to make VT1, else cross join VT1 and the next JOIN. Go step 2.
2. ON: The ON filter is applied to VT1. Only rows for which the <join_condition> is TRUE are inserted to VT2.
3. OUTER (join): If an OUTER JOIN is specified (as opposed to an INNER JOIN), rows from the preserved table or tables for which a match was not found are added to the rows from VT2 as outer rows, generating VT3. If more than two tables appear in the FROM clause, steps 1 through 3 are applied repeatedly between the result of the last join and the next table in the FROM clause until all tables are processed.
4. WHERE: The WHERE filter is applied to VT3. Only rows for which the <where_condition> is TRUE are inserted to VT4.
5. GROUP BY: The rows from VT4 are arranged in groups based on the column list specified in the GROUP BY clause. VT5 is generated.
6. CUBE | ROLLUP: Supergroups (groups of groups) are added to the rows from VT5, generating VT6.
7. HAVING: The HAVING filter is applied to VT6. Only groups for which the <having_condition> is TRUE are inserted to VT7.
8. SELECT: The SELECT list is processed, generating VT8.
9. DISTINCT: Duplicate rows are removed from VT8. VT9 is generated.
10. ORDER BY: The rows from VT9 are sorted according to the column list specified in the ORDER BY clause. A cursor is generated (VC10).
11. TOP: The specified number or percentage of rows is selected from the beginning of VC10. Table VT11 is generated and returned to the caller.

reference: stack overflow #1018822

Trait Implementations

impl Debug for SQL

fn fmt(&self, f: &mut Formatter) -> Result

Formats the value using the given formatter.