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

272 lines
9.6 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
*/
LibSQL: Implement LIKE SQL expressions
2021-12-29 11:47:29 -03:00
#include <LibRegex/Regex.h>
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
#include <LibSQL/AST/AST.h>
#include <LibSQL/Database.h>
namespace SQL::AST {
LibSQL: Implement LIKE SQL expressions
2021-12-29 11:47:29 -03:00
static const String s_posix_basic_metacharacters = ".^$*[]+\\";
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::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) {
LibSQL: Improve error handling The handling of filesystem level errors was basically non-existing or consisting of `VERIFY_NOT_REACHED` assertions. Addressed this by * Adding `open` methods to `Heap` and `Database` which return errors. * Changing the interface of methods of these classes and clients downstream to propagate these errors. The constructors of `Heap` and `Database` don't open the underlying filesystem file anymore. The SQL statement handlers return an `SQLErrorCode::InternalError` error code if an error comes back from the lower levels. Note that some of these errors are things like duplicate index entry errors that should be caught before the SQL layer attempts to actually update the database. Added tests to catch attempts to open weird or non-existent files as databases. Finally, in between me writing this patch and submitting the PR the AK::Result<Foo, Bar> template got deprecated in favour of ErrorOr<Foo>. This resulted in more busywork.
2021-11-05 19:05:59 -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
}
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
}
LibSQL: Improve error handling The handling of filesystem level errors was basically non-existing or consisting of `VERIFY_NOT_REACHED` assertions. Addressed this by * Adding `open` methods to `Heap` and `Database` which return errors. * Changing the interface of methods of these classes and clients downstream to propagate these errors. The constructors of `Heap` and `Database` don't open the underlying filesystem file anymore. The SQL statement handlers return an `SQLErrorCode::InternalError` error code if an error comes back from the lower levels. Note that some of these errors are things like duplicate index entry errors that should be caught before the SQL layer attempts to actually update the database. Added tests to catch attempts to open weird or non-existent files as databases. Finally, in between me writing this patch and submitting the PR the AK::Result<Foo, Bar> template got deprecated in favour of ErrorOr<Foo>. This resulted in more busywork.
2021-11-05 19:05:59 -04:00
return Value(lhs_bool_maybe.release_value() && rhs_bool_maybe.release_value());
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
}
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
}
LibSQL: Improve error handling The handling of filesystem level errors was basically non-existing or consisting of `VERIFY_NOT_REACHED` assertions. Addressed this by * Adding `open` methods to `Heap` and `Database` which return errors. * Changing the interface of methods of these classes and clients downstream to propagate these errors. The constructors of `Heap` and `Database` don't open the underlying filesystem file anymore. The SQL statement handlers return an `SQLErrorCode::InternalError` error code if an error comes back from the lower levels. Note that some of these errors are things like duplicate index entry errors that should be caught before the SQL layer attempts to actually update the database. Added tests to catch attempts to open weird or non-existent files as databases. Finally, in between me writing this patch and submitting the PR the AK::Result<Foo, Bar> template got deprecated in favour of ErrorOr<Foo>. This resulted in more busywork.
2021-11-05 19:05:59 -04:00
return Value(lhs_bool_maybe.release_value() || rhs_bool_maybe.release_value());
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: 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
{
LibSQL: Gracefully react to unimplemented valid SQL Fixes a crash that was caused by a syntax error which is difficult to catch by the parser: usually identifiers are accepted in column lists, but they are not in a list of column values to be inserted in an INSERT. Fixed this by putting in a heuristic check; we probably need a better way to do this. Included tests for this case. Also introduced a new SQL Error code, `NotYetImplemented`, and return that instead of crashing when encountering unimplemented SQL.
2021-11-13 17:30:29 -05:00
if (!context.current_row) {
context.result->set_error(SQLErrorCode::SyntaxError, 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
auto& descriptor = *context.current_row->descriptor();
VERIFY(context.current_row->size() == descriptor.size());
LibSQL: Implement table joins This patch introduces table joins. It uses a pretty dumb algorithm- starting with a singleton '__unity__' row consisting of a single boolean value, a cartesian product of all tables in the 'FROM' clause is built. This cartesian product is then filtered through the 'WHERE' clause, again without any smarts just using brute force. This patch required a bunch of busy work to allow for example the ColumnNameExpression having to deal with multiple tables potentially having columns with the same name.
2021-11-02 16:49:54 -04:00
Optional<size_t> index_in_row;
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
for (auto ix = 0u; ix < context.current_row->size(); ix++) {
auto& column_descriptor = descriptor[ix];
LibSQL: Implement table joins This patch introduces table joins. It uses a pretty dumb algorithm- starting with a singleton '__unity__' row consisting of a single boolean value, a cartesian product of all tables in the 'FROM' clause is built. This cartesian product is then filtered through the 'WHERE' clause, again without any smarts just using brute force. This patch required a bunch of busy work to allow for example the ColumnNameExpression having to deal with multiple tables potentially having columns with the same name.
2021-11-02 16:49:54 -04:00
if (!table_name().is_empty() && column_descriptor.table != table_name())
continue;
if (column_descriptor.name == column_name()) {
if (index_in_row.has_value()) {
context.result->set_error(SQLErrorCode::AmbiguousColumnName, column_name());
return Value::null();
}
index_in_row = ix;
}
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: Implement table joins This patch introduces table joins. It uses a pretty dumb algorithm- starting with a singleton '__unity__' row consisting of a single boolean value, a cartesian product of all tables in the 'FROM' clause is built. This cartesian product is then filtered through the 'WHERE' clause, again without any smarts just using brute force. This patch required a bunch of busy work to allow for example the ColumnNameExpression having to deal with multiple tables potentially having columns with the same name.
2021-11-02 16:49:54 -04:00
if (index_in_row.has_value())
return (*context.current_row)[index_in_row.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::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: Implement LIKE SQL expressions
2021-12-29 11:47:29 -03:00
Value MatchExpression::evaluate(ExecutionContext& context) const
{
if (context.result->has_error())
return Value::null();
switch (type()) {
case MatchOperator::Like: {
Value lhs_value = lhs()->evaluate(context);
Value rhs_value = rhs()->evaluate(context);
char escape_char = '\0';
if (escape()) {
auto escape_str = escape()->evaluate(context).to_string();
if (escape_str.length() != 1) {
context.result->set_error(SQLErrorCode::SyntaxError, "ESCAPE should be a single character");
return Value::null();
}
escape_char = escape_str[0];
}
// Compile the pattern into a simple regex.
// https://sqlite.org/lang_expr.html#the_like_glob_regexp_and_match_operators
bool escaped = false;
AK::StringBuilder builder;
builder.append('^');
for (auto c : rhs_value.to_string()) {
if (escape() && c == escape_char && !escaped) {
escaped = true;
} else if (s_posix_basic_metacharacters.contains(c)) {
escaped = false;
builder.append('\\');
builder.append(c);
} else if (c == '_' && !escaped) {
builder.append('.');
} else if (c == '%' && !escaped) {
builder.append(".*");
} else {
escaped = false;
builder.append(c);
}
}
builder.append('$');
// FIXME: We should probably cache this regex.
auto regex = Regex<PosixBasic>(builder.build());
auto result = regex.match(lhs_value.to_string(), PosixFlags::Insensitive | PosixFlags::Unicode);
return Value(invert_expression() ? !result.success : result.success);
}
LibSQL: Add simple REGEXP match The implementation of LIKE uses regexes under the hood, and this implementation of REGEXP takes the same approach. It employs PosixExtended from LibRegex with case insensitive and Unicode flags set. The implementation of LIKE is based on SQLlite specs, but SQLlite does not offer directions for a built-in regex functionality, so this one uses LibRegex.
2022-01-22 15:43:30 +01:00
case MatchOperator::Regexp: {
Value lhs_value = lhs()->evaluate(context);
Value rhs_value = rhs()->evaluate(context);
auto regex = Regex<PosixExtended>(rhs_value.to_string());
auto err = regex.parser_result.error;
if (err != regex::Error::NoError) {
StringBuilder builder;
builder.append("Regular expression: ");
builder.append(get_error_string(err));
context.result->set_error(SQLErrorCode::SyntaxError, builder.build());
return Value(false);
}
auto result = regex.match(lhs_value.to_string(), PosixFlags::Insensitive | PosixFlags::Unicode);
return Value(invert_expression() ? !result.success : result.success);
}
LibSQL: Implement LIKE SQL expressions
2021-12-29 11:47:29 -03:00
case MatchOperator::Glob:
case MatchOperator::Match:
default:
VERIFY_NOT_REACHED();
}
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
}
Reference in a new issue Copy permalink