Stowage/ladybird
2
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-11-07 00:30:59 +00:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Userland/Libraries/LibSQL/AST/Expression.cpp

183 lines
6.2 KiB
C++
Raw Normal View History

LibSQL+SQLServer: Bare bones INSERT and SELECT statements This patch provides very basic, bare bones implementations of the INSERT and SELECT statements. They are *very* limited: - The only variant of the INSERT statement that currently works is SELECT INTO schema.table (column1, column2, ....) VALUES (value11, value21, ...), (value12, value22, ...), ... where the values are literals. - The SELECT statement is even more limited, and is only provided to allow verification of the INSERT statement. The only form implemented is: SELECT * FROM schema.table These statements required a bit of change in the Statement::execute API. Originally execute only received a Database object as parameter. This is not enough; we now pass an ExecutionContext object which contains the Database, the current result set, and the last Tuple read from the database. This object will undoubtedly evolve over time. This API change dragged SQLServer::SQLStatement into the patch. Another API addition is Expression::evaluate. This method is, unsurprisingly, used to evaluate expressions, like the values in the INSERT statement. Finally, a new test file is added: TestSqlStatementExecution, which tests the currently implemented statements. As the number and flavour of implemented statements grows, this test file will probably have to be restructured.
2021-07-19 19:48:46 -04:00
/*
* Copyright (c) 2021, Jan de Visser <jan@de-visser.net>
*
* SPDX-License-Identifier: BSD-2-Clause
*/
#include <LibSQL/AST/AST.h>
#include <LibSQL/Database.h>
namespace SQL::AST {
Value Expression::evaluate(ExecutionContext&) const
{
return Value::null();
}
LibSQL: Add better error handling to `evaluate` and `execute` methods There was a lot of `VERIFY_NOT_REACHED` error handling going on. Fixed most of those. A bit of a caveat is that after every `evaluate` call for expressions that are part of a statement the error status of the `SQLResult` return value must be called.
2021-10-23 10:46:33 -04:00
Value NumericLiteral::evaluate(ExecutionContext& context) const
LibSQL+SQLServer: Bare bones INSERT and SELECT statements This patch provides very basic, bare bones implementations of the INSERT and SELECT statements. They are *very* limited: - The only variant of the INSERT statement that currently works is SELECT INTO schema.table (column1, column2, ....) VALUES (value11, value21, ...), (value12, value22, ...), ... where the values are literals. - The SELECT statement is even more limited, and is only provided to allow verification of the INSERT statement. The only form implemented is: SELECT * FROM schema.table These statements required a bit of change in the Statement::execute API. Originally execute only received a Database object as parameter. This is not enough; we now pass an ExecutionContext object which contains the Database, the current result set, and the last Tuple read from the database. This object will undoubtedly evolve over time. This API change dragged SQLServer::SQLStatement into the patch. Another API addition is Expression::evaluate. This method is, unsurprisingly, used to evaluate expressions, like the values in the INSERT statement. Finally, a new test file is added: TestSqlStatementExecution, which tests the currently implemented statements. As the number and flavour of implemented statements grows, this test file will probably have to be restructured.
2021-07-19 19:48:46 -04:00
{
LibSQL: Add better error handling to `evaluate` and `execute` methods There was a lot of `VERIFY_NOT_REACHED` error handling going on. Fixed most of those. A bit of a caveat is that after every `evaluate` call for expressions that are part of a statement the error status of the `SQLResult` return value must be called.
2021-10-23 10:46:33 -04:00
if (context.result->has_error())
return Value::null();
LibSQL+SQLServer: Bare bones INSERT and SELECT statements This patch provides very basic, bare bones implementations of the INSERT and SELECT statements. They are *very* limited: - The only variant of the INSERT statement that currently works is SELECT INTO schema.table (column1, column2, ....) VALUES (value11, value21, ...), (value12, value22, ...), ... where the values are literals. - The SELECT statement is even more limited, and is only provided to allow verification of the INSERT statement. The only form implemented is: SELECT * FROM schema.table These statements required a bit of change in the Statement::execute API. Originally execute only received a Database object as parameter. This is not enough; we now pass an ExecutionContext object which contains the Database, the current result set, and the last Tuple read from the database. This object will undoubtedly evolve over time. This API change dragged SQLServer::SQLStatement into the patch. Another API addition is Expression::evaluate. This method is, unsurprisingly, used to evaluate expressions, like the values in the INSERT statement. Finally, a new test file is added: TestSqlStatementExecution, which tests the currently implemented statements. As the number and flavour of implemented statements grows, this test file will probably have to be restructured.
2021-07-19 19:48:46 -04:00
Value ret(SQLType::Float);
ret = value();
return ret;
}
LibSQL: Add better error handling to `evaluate` and `execute` methods There was a lot of `VERIFY_NOT_REACHED` error handling going on. Fixed most of those. A bit of a caveat is that after every `evaluate` call for expressions that are part of a statement the error status of the `SQLResult` return value must be called.
2021-10-23 10:46:33 -04:00
Value StringLiteral::evaluate(ExecutionContext& context) const
LibSQL+SQLServer: Bare bones INSERT and SELECT statements This patch provides very basic, bare bones implementations of the INSERT and SELECT statements. They are *very* limited: - The only variant of the INSERT statement that currently works is SELECT INTO schema.table (column1, column2, ....) VALUES (value11, value21, ...), (value12, value22, ...), ... where the values are literals. - The SELECT statement is even more limited, and is only provided to allow verification of the INSERT statement. The only form implemented is: SELECT * FROM schema.table These statements required a bit of change in the Statement::execute API. Originally execute only received a Database object as parameter. This is not enough; we now pass an ExecutionContext object which contains the Database, the current result set, and the last Tuple read from the database. This object will undoubtedly evolve over time. This API change dragged SQLServer::SQLStatement into the patch. Another API addition is Expression::evaluate. This method is, unsurprisingly, used to evaluate expressions, like the values in the INSERT statement. Finally, a new test file is added: TestSqlStatementExecution, which tests the currently implemented statements. As the number and flavour of implemented statements grows, this test file will probably have to be restructured.
2021-07-19 19:48:46 -04:00
{
LibSQL: Add better error handling to `evaluate` and `execute` methods There was a lot of `VERIFY_NOT_REACHED` error handling going on. Fixed most of those. A bit of a caveat is that after every `evaluate` call for expressions that are part of a statement the error status of the `SQLResult` return value must be called.
2021-10-23 10:46:33 -04:00
if (context.result->has_error())
return Value::null();
LibSQL+SQLServer: Bare bones INSERT and SELECT statements This patch provides very basic, bare bones implementations of the INSERT and SELECT statements. They are *very* limited: - The only variant of the INSERT statement that currently works is SELECT INTO schema.table (column1, column2, ....) VALUES (value11, value21, ...), (value12, value22, ...), ... where the values are literals. - The SELECT statement is even more limited, and is only provided to allow verification of the INSERT statement. The only form implemented is: SELECT * FROM schema.table These statements required a bit of change in the Statement::execute API. Originally execute only received a Database object as parameter. This is not enough; we now pass an ExecutionContext object which contains the Database, the current result set, and the last Tuple read from the database. This object will undoubtedly evolve over time. This API change dragged SQLServer::SQLStatement into the patch. Another API addition is Expression::evaluate. This method is, unsurprisingly, used to evaluate expressions, like the values in the INSERT statement. Finally, a new test file is added: TestSqlStatementExecution, which tests the currently implemented statements. As the number and flavour of implemented statements grows, this test file will probably have to be restructured.
2021-07-19 19:48:46 -04:00
Value ret(SQLType::Text);
ret = value();
return ret;
}
Value NullLiteral::evaluate(ExecutionContext&) const
{
return Value::null();
}
Value NestedExpression::evaluate(ExecutionContext& context) const
{
LibSQL: Add better error handling to `evaluate` and `execute` methods There was a lot of `VERIFY_NOT_REACHED` error handling going on. Fixed most of those. A bit of a caveat is that after every `evaluate` call for expressions that are part of a statement the error status of the `SQLResult` return value must be called.
2021-10-23 10:46:33 -04:00
if (context.result->has_error())
return Value::null();
LibSQL+SQLServer: Bare bones INSERT and SELECT statements This patch provides very basic, bare bones implementations of the INSERT and SELECT statements. They are *very* limited: - The only variant of the INSERT statement that currently works is SELECT INTO schema.table (column1, column2, ....) VALUES (value11, value21, ...), (value12, value22, ...), ... where the values are literals. - The SELECT statement is even more limited, and is only provided to allow verification of the INSERT statement. The only form implemented is: SELECT * FROM schema.table These statements required a bit of change in the Statement::execute API. Originally execute only received a Database object as parameter. This is not enough; we now pass an ExecutionContext object which contains the Database, the current result set, and the last Tuple read from the database. This object will undoubtedly evolve over time. This API change dragged SQLServer::SQLStatement into the patch. Another API addition is Expression::evaluate. This method is, unsurprisingly, used to evaluate expressions, like the values in the INSERT statement. Finally, a new test file is added: TestSqlStatementExecution, which tests the currently implemented statements. As the number and flavour of implemented statements grows, this test file will probably have to be restructured.
2021-07-19 19:48:46 -04:00
return expression()->evaluate(context);
}
Value ChainedExpression::evaluate(ExecutionContext& context) const
{
LibSQL: Add better error handling to `evaluate` and `execute` methods There was a lot of `VERIFY_NOT_REACHED` error handling going on. Fixed most of those. A bit of a caveat is that after every `evaluate` call for expressions that are part of a statement the error status of the `SQLResult` return value must be called.
2021-10-23 10:46:33 -04:00
if (context.result->has_error())
return Value::null();
LibSQL+SQLServer: Bare bones INSERT and SELECT statements This patch provides very basic, bare bones implementations of the INSERT and SELECT statements. They are *very* limited: - The only variant of the INSERT statement that currently works is SELECT INTO schema.table (column1, column2, ....) VALUES (value11, value21, ...), (value12, value22, ...), ... where the values are literals. - The SELECT statement is even more limited, and is only provided to allow verification of the INSERT statement. The only form implemented is: SELECT * FROM schema.table These statements required a bit of change in the Statement::execute API. Originally execute only received a Database object as parameter. This is not enough; we now pass an ExecutionContext object which contains the Database, the current result set, and the last Tuple read from the database. This object will undoubtedly evolve over time. This API change dragged SQLServer::SQLStatement into the patch. Another API addition is Expression::evaluate. This method is, unsurprisingly, used to evaluate expressions, like the values in the INSERT statement. Finally, a new test file is added: TestSqlStatementExecution, which tests the currently implemented statements. As the number and flavour of implemented statements grows, this test file will probably have to be restructured.
2021-07-19 19:48:46 -04:00
Value ret(SQLType::Tuple);
Vector<Value> values;
for (auto& expression : expressions()) {
values.append(expression.evaluate(context));
}
ret = values;
return ret;
}
LibSQL: Implement evaluate() method of BinaryOperatorExpression Mostly just calls the appropriate methods on the Value objects. Exception are the `Concatenate` (string concat), and the logical `and` and `or` operators which are implemented directly in `BinaryOperatorExpression::evaluate`
2021-10-21 18:10:25 -04:00
Value BinaryOperatorExpression::evaluate(ExecutionContext& context) const
{
LibSQL: Add better error handling to `evaluate` and `execute` methods There was a lot of `VERIFY_NOT_REACHED` error handling going on. Fixed most of those. A bit of a caveat is that after every `evaluate` call for expressions that are part of a statement the error status of the `SQLResult` return value must be called.
2021-10-23 10:46:33 -04:00
if (context.result->has_error())
return Value::null();
LibSQL: Implement evaluate() method of BinaryOperatorExpression Mostly just calls the appropriate methods on the Value objects. Exception are the `Concatenate` (string concat), and the logical `and` and `or` operators which are implemented directly in `BinaryOperatorExpression::evaluate`
2021-10-21 18:10:25 -04:00
Value lhs_value = lhs()->evaluate(context);
Value rhs_value = rhs()->evaluate(context);
switch (type()) {
case BinaryOperator::Concatenate: {
if (lhs_value.type() != SQLType::Text) {
VERIFY_NOT_REACHED();
}
AK::StringBuilder builder;
builder.append(lhs_value.to_string());
builder.append(rhs_value.to_string());
return Value(builder.to_string());
}
case BinaryOperator::Multiplication:
return lhs_value.multiply(rhs_value);
case BinaryOperator::Division:
return lhs_value.divide(rhs_value);
case BinaryOperator::Modulo:
return lhs_value.modulo(rhs_value);
case BinaryOperator::Plus:
return lhs_value.add(rhs_value);
case BinaryOperator::Minus:
return lhs_value.subtract(rhs_value);
case BinaryOperator::ShiftLeft:
return lhs_value.shift_left(rhs_value);
case BinaryOperator::ShiftRight:
return lhs_value.shift_right(rhs_value);
case BinaryOperator::BitwiseAnd:
return lhs_value.bitwise_and(rhs_value);
case BinaryOperator::BitwiseOr:
return lhs_value.bitwise_or(rhs_value);
case BinaryOperator::LessThan:
return Value(lhs_value.compare(rhs_value) < 0);
case BinaryOperator::LessThanEquals:
return Value(lhs_value.compare(rhs_value) <= 0);
case BinaryOperator::GreaterThan:
return Value(lhs_value.compare(rhs_value) > 0);
case BinaryOperator::GreaterThanEquals:
return Value(lhs_value.compare(rhs_value) >= 0);
case BinaryOperator::Equals:
return Value(lhs_value.compare(rhs_value) == 0);
case BinaryOperator::NotEquals:
return Value(lhs_value.compare(rhs_value) != 0);
case BinaryOperator::And: {
auto lhs_bool_maybe = lhs_value.to_bool();
auto rhs_bool_maybe = rhs_value.to_bool();
if (!lhs_bool_maybe.has_value() || !rhs_bool_maybe.has_value()) {
LibSQL: Add better error handling to `evaluate` and `execute` methods There was a lot of `VERIFY_NOT_REACHED` error handling going on. Fixed most of those. A bit of a caveat is that after every `evaluate` call for expressions that are part of a statement the error status of the `SQLResult` return value must be called.
2021-10-23 10:46:33 -04:00
context.result->set_error(SQLErrorCode::BooleanOperatorTypeMismatch, BinaryOperator_name(type()));
return Value::null();
LibSQL: Implement evaluate() method of BinaryOperatorExpression Mostly just calls the appropriate methods on the Value objects. Exception are the `Concatenate` (string concat), and the logical `and` and `or` operators which are implemented directly in `BinaryOperatorExpression::evaluate`
2021-10-21 18:10:25 -04:00
}
return Value(lhs_bool_maybe.value() && rhs_bool_maybe.value());
}
case BinaryOperator::Or: {
auto lhs_bool_maybe = lhs_value.to_bool();
auto rhs_bool_maybe = rhs_value.to_bool();
if (!lhs_bool_maybe.has_value() || !rhs_bool_maybe.has_value()) {
LibSQL: Add better error handling to `evaluate` and `execute` methods There was a lot of `VERIFY_NOT_REACHED` error handling going on. Fixed most of those. A bit of a caveat is that after every `evaluate` call for expressions that are part of a statement the error status of the `SQLResult` return value must be called.
2021-10-23 10:46:33 -04:00
context.result->set_error(SQLErrorCode::BooleanOperatorTypeMismatch, BinaryOperator_name(type()));
return Value::null();
LibSQL: Implement evaluate() method of BinaryOperatorExpression Mostly just calls the appropriate methods on the Value objects. Exception are the `Concatenate` (string concat), and the logical `and` and `or` operators which are implemented directly in `BinaryOperatorExpression::evaluate`
2021-10-21 18:10:25 -04:00
}
return Value(lhs_bool_maybe.value() || rhs_bool_maybe.value());
}
LibSQL: Add better error handling to `evaluate` and `execute` methods There was a lot of `VERIFY_NOT_REACHED` error handling going on. Fixed most of those. A bit of a caveat is that after every `evaluate` call for expressions that are part of a statement the error status of the `SQLResult` return value must be called.
2021-10-23 10:46:33 -04:00
default:
VERIFY_NOT_REACHED();
LibSQL: Implement evaluate() method of BinaryOperatorExpression Mostly just calls the appropriate methods on the Value objects. Exception are the `Concatenate` (string concat), and the logical `and` and `or` operators which are implemented directly in `BinaryOperatorExpression::evaluate`
2021-10-21 18:10:25 -04:00
}
}
LibSQL+SQLServer: Bare bones INSERT and SELECT statements This patch provides very basic, bare bones implementations of the INSERT and SELECT statements. They are *very* limited: - The only variant of the INSERT statement that currently works is SELECT INTO schema.table (column1, column2, ....) VALUES (value11, value21, ...), (value12, value22, ...), ... where the values are literals. - The SELECT statement is even more limited, and is only provided to allow verification of the INSERT statement. The only form implemented is: SELECT * FROM schema.table These statements required a bit of change in the Statement::execute API. Originally execute only received a Database object as parameter. This is not enough; we now pass an ExecutionContext object which contains the Database, the current result set, and the last Tuple read from the database. This object will undoubtedly evolve over time. This API change dragged SQLServer::SQLStatement into the patch. Another API addition is Expression::evaluate. This method is, unsurprisingly, used to evaluate expressions, like the values in the INSERT statement. Finally, a new test file is added: TestSqlStatementExecution, which tests the currently implemented statements. As the number and flavour of implemented statements grows, this test file will probably have to be restructured.
2021-07-19 19:48:46 -04:00
Value UnaryOperatorExpression::evaluate(ExecutionContext& context) const
{
LibSQL: Add better error handling to `evaluate` and `execute` methods There was a lot of `VERIFY_NOT_REACHED` error handling going on. Fixed most of those. A bit of a caveat is that after every `evaluate` call for expressions that are part of a statement the error status of the `SQLResult` return value must be called.
2021-10-23 10:46:33 -04:00
if (context.result->has_error())
return Value::null();
LibSQL+SQLServer: Bare bones INSERT and SELECT statements This patch provides very basic, bare bones implementations of the INSERT and SELECT statements. They are *very* limited: - The only variant of the INSERT statement that currently works is SELECT INTO schema.table (column1, column2, ....) VALUES (value11, value21, ...), (value12, value22, ...), ... where the values are literals. - The SELECT statement is even more limited, and is only provided to allow verification of the INSERT statement. The only form implemented is: SELECT * FROM schema.table These statements required a bit of change in the Statement::execute API. Originally execute only received a Database object as parameter. This is not enough; we now pass an ExecutionContext object which contains the Database, the current result set, and the last Tuple read from the database. This object will undoubtedly evolve over time. This API change dragged SQLServer::SQLStatement into the patch. Another API addition is Expression::evaluate. This method is, unsurprisingly, used to evaluate expressions, like the values in the INSERT statement. Finally, a new test file is added: TestSqlStatementExecution, which tests the currently implemented statements. As the number and flavour of implemented statements grows, this test file will probably have to be restructured.
2021-07-19 19:48:46 -04:00
Value expression_value = NestedExpression::evaluate(context);
switch (type()) {
case UnaryOperator::Plus:
if (expression_value.type() == SQLType::Integer || expression_value.type() == SQLType::Float)
return expression_value;
LibSQL: Add better error handling to `evaluate` and `execute` methods There was a lot of `VERIFY_NOT_REACHED` error handling going on. Fixed most of those. A bit of a caveat is that after every `evaluate` call for expressions that are part of a statement the error status of the `SQLResult` return value must be called.
2021-10-23 10:46:33 -04:00
context.result->set_error(SQLErrorCode::NumericOperatorTypeMismatch, UnaryOperator_name(type()));
return Value::null();
LibSQL+SQLServer: Bare bones INSERT and SELECT statements This patch provides very basic, bare bones implementations of the INSERT and SELECT statements. They are *very* limited: - The only variant of the INSERT statement that currently works is SELECT INTO schema.table (column1, column2, ....) VALUES (value11, value21, ...), (value12, value22, ...), ... where the values are literals. - The SELECT statement is even more limited, and is only provided to allow verification of the INSERT statement. The only form implemented is: SELECT * FROM schema.table These statements required a bit of change in the Statement::execute API. Originally execute only received a Database object as parameter. This is not enough; we now pass an ExecutionContext object which contains the Database, the current result set, and the last Tuple read from the database. This object will undoubtedly evolve over time. This API change dragged SQLServer::SQLStatement into the patch. Another API addition is Expression::evaluate. This method is, unsurprisingly, used to evaluate expressions, like the values in the INSERT statement. Finally, a new test file is added: TestSqlStatementExecution, which tests the currently implemented statements. As the number and flavour of implemented statements grows, this test file will probably have to be restructured.
2021-07-19 19:48:46 -04:00
case UnaryOperator::Minus:
if (expression_value.type() == SQLType::Integer) {
expression_value = -int(expression_value);
return expression_value;
}
if (expression_value.type() == SQLType::Float) {
expression_value = -double(expression_value);
return expression_value;
}
LibSQL: Add better error handling to `evaluate` and `execute` methods There was a lot of `VERIFY_NOT_REACHED` error handling going on. Fixed most of those. A bit of a caveat is that after every `evaluate` call for expressions that are part of a statement the error status of the `SQLResult` return value must be called.
2021-10-23 10:46:33 -04:00
context.result->set_error(SQLErrorCode::NumericOperatorTypeMismatch, UnaryOperator_name(type()));
return Value::null();
LibSQL+SQLServer: Bare bones INSERT and SELECT statements This patch provides very basic, bare bones implementations of the INSERT and SELECT statements. They are *very* limited: - The only variant of the INSERT statement that currently works is SELECT INTO schema.table (column1, column2, ....) VALUES (value11, value21, ...), (value12, value22, ...), ... where the values are literals. - The SELECT statement is even more limited, and is only provided to allow verification of the INSERT statement. The only form implemented is: SELECT * FROM schema.table These statements required a bit of change in the Statement::execute API. Originally execute only received a Database object as parameter. This is not enough; we now pass an ExecutionContext object which contains the Database, the current result set, and the last Tuple read from the database. This object will undoubtedly evolve over time. This API change dragged SQLServer::SQLStatement into the patch. Another API addition is Expression::evaluate. This method is, unsurprisingly, used to evaluate expressions, like the values in the INSERT statement. Finally, a new test file is added: TestSqlStatementExecution, which tests the currently implemented statements. As the number and flavour of implemented statements grows, this test file will probably have to be restructured.
2021-07-19 19:48:46 -04:00
case UnaryOperator::Not:
if (expression_value.type() == SQLType::Boolean) {
expression_value = !bool(expression_value);
return expression_value;
}
LibSQL: Add better error handling to `evaluate` and `execute` methods There was a lot of `VERIFY_NOT_REACHED` error handling going on. Fixed most of those. A bit of a caveat is that after every `evaluate` call for expressions that are part of a statement the error status of the `SQLResult` return value must be called.
2021-10-23 10:46:33 -04:00
context.result->set_error(SQLErrorCode::BooleanOperatorTypeMismatch, UnaryOperator_name(type()));
return Value::null();
LibSQL+SQLServer: Bare bones INSERT and SELECT statements This patch provides very basic, bare bones implementations of the INSERT and SELECT statements. They are *very* limited: - The only variant of the INSERT statement that currently works is SELECT INTO schema.table (column1, column2, ....) VALUES (value11, value21, ...), (value12, value22, ...), ... where the values are literals. - The SELECT statement is even more limited, and is only provided to allow verification of the INSERT statement. The only form implemented is: SELECT * FROM schema.table These statements required a bit of change in the Statement::execute API. Originally execute only received a Database object as parameter. This is not enough; we now pass an ExecutionContext object which contains the Database, the current result set, and the last Tuple read from the database. This object will undoubtedly evolve over time. This API change dragged SQLServer::SQLStatement into the patch. Another API addition is Expression::evaluate. This method is, unsurprisingly, used to evaluate expressions, like the values in the INSERT statement. Finally, a new test file is added: TestSqlStatementExecution, which tests the currently implemented statements. As the number and flavour of implemented statements grows, this test file will probably have to be restructured.
2021-07-19 19:48:46 -04:00
case UnaryOperator::BitwiseNot:
if (expression_value.type() == SQLType::Integer) {
expression_value = ~u32(expression_value);
return expression_value;
}
LibSQL: Add better error handling to `evaluate` and `execute` methods There was a lot of `VERIFY_NOT_REACHED` error handling going on. Fixed most of those. A bit of a caveat is that after every `evaluate` call for expressions that are part of a statement the error status of the `SQLResult` return value must be called.
2021-10-23 10:46:33 -04:00
context.result->set_error(SQLErrorCode::IntegerOperatorTypeMismatch, UnaryOperator_name(type()));
return Value::null();
LibSQL+SQLServer: Bare bones INSERT and SELECT statements This patch provides very basic, bare bones implementations of the INSERT and SELECT statements. They are *very* limited: - The only variant of the INSERT statement that currently works is SELECT INTO schema.table (column1, column2, ....) VALUES (value11, value21, ...), (value12, value22, ...), ... where the values are literals. - The SELECT statement is even more limited, and is only provided to allow verification of the INSERT statement. The only form implemented is: SELECT * FROM schema.table These statements required a bit of change in the Statement::execute API. Originally execute only received a Database object as parameter. This is not enough; we now pass an ExecutionContext object which contains the Database, the current result set, and the last Tuple read from the database. This object will undoubtedly evolve over time. This API change dragged SQLServer::SQLStatement into the patch. Another API addition is Expression::evaluate. This method is, unsurprisingly, used to evaluate expressions, like the values in the INSERT statement. Finally, a new test file is added: TestSqlStatementExecution, which tests the currently implemented statements. As the number and flavour of implemented statements grows, this test file will probably have to be restructured.
2021-07-19 19:48:46 -04:00
}
VERIFY_NOT_REACHED();
}
LibSQL: Allow expressions and column names in SELECT ... FROM Up to now the only ``SELECT`` statement that worked was ``SELECT * FROM <table>``. This commit allows a column list consisting of column names and expressions in addition to ``*``. ``WHERE`` still doesn't work though.
2021-09-16 22:29:19 +02:00
Value ColumnNameExpression::evaluate(ExecutionContext& context) const
{
auto& descriptor = *context.current_row->descriptor();
VERIFY(context.current_row->size() == descriptor.size());
for (auto ix = 0u; ix < context.current_row->size(); ix++) {
auto& column_descriptor = descriptor[ix];
if (column_descriptor.name == column_name())
return { (*context.current_row)[ix] };
}
LibSQL: Add better error handling to `evaluate` and `execute` methods There was a lot of `VERIFY_NOT_REACHED` error handling going on. Fixed most of those. A bit of a caveat is that after every `evaluate` call for expressions that are part of a statement the error status of the `SQLResult` return value must be called.
2021-10-23 10:46:33 -04:00
context.result->set_error(SQLErrorCode::ColumnDoesNotExist, column_name());
return Value::null();
LibSQL: Allow expressions and column names in SELECT ... FROM Up to now the only ``SELECT`` statement that worked was ``SELECT * FROM <table>``. This commit allows a column list consisting of column names and expressions in addition to ``*``. ``WHERE`` still doesn't work though.
2021-09-16 22:29:19 +02:00
}
LibSQL+SQLServer: Bare bones INSERT and SELECT statements This patch provides very basic, bare bones implementations of the INSERT and SELECT statements. They are *very* limited: - The only variant of the INSERT statement that currently works is SELECT INTO schema.table (column1, column2, ....) VALUES (value11, value21, ...), (value12, value22, ...), ... where the values are literals. - The SELECT statement is even more limited, and is only provided to allow verification of the INSERT statement. The only form implemented is: SELECT * FROM schema.table These statements required a bit of change in the Statement::execute API. Originally execute only received a Database object as parameter. This is not enough; we now pass an ExecutionContext object which contains the Database, the current result set, and the last Tuple read from the database. This object will undoubtedly evolve over time. This API change dragged SQLServer::SQLStatement into the patch. Another API addition is Expression::evaluate. This method is, unsurprisingly, used to evaluate expressions, like the values in the INSERT statement. Finally, a new test file is added: TestSqlStatementExecution, which tests the currently implemented statements. As the number and flavour of implemented statements grows, this test file will probably have to be restructured.
2021-07-19 19:48:46 -04:00
}
Reference in a new issue Copy permalink