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>
|
2022-03-13 16:09:41 -06:00
|
|
|
* Copyright (c) 2022, the SerenityOS developers.
|
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
|
|
|
*
|
|
|
|
|
* SPDX-License-Identifier: BSD-2-Clause
|
|
|
|
|
*/
|
|
|
|
|
|
2022-03-13 16:09:41 -06:00
|
|
|
#include <AK/StringView.h>
|
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 {
|
|
|
|
|
|
2022-07-11 17:32:29 +00:00
|
|
|
static constexpr auto s_posix_basic_metacharacters = ".^$*[]+\\"sv;
|
2021-12-29 11:47:29 -03:00
|
|
|
|
2022-02-10 07:46:36 -05:00
|
|
|
ResultOr<Value> NumericLiteral::evaluate(ExecutionContext&) 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: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
return Value { value() };
|
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
|
|
|
}
|
|
|
|
|
|
2022-02-10 07:46:36 -05:00
|
|
|
ResultOr<Value> StringLiteral::evaluate(ExecutionContext&) 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: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
return Value { value() };
|
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
|
|
|
}
|
|
|
|
|
|
2022-02-10 07:46:36 -05:00
|
|
|
ResultOr<Value> NullLiteral::evaluate(ExecutionContext&) 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: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
return Value {};
|
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
|
|
|
}
|
|
|
|
|
|
2022-12-01 22:20:55 -05:00
|
|
|
ResultOr<Value> Placeholder::evaluate(ExecutionContext& context) const
|
|
|
|
|
{
|
|
|
|
|
if (parameter_index() >= context.placeholder_values.size())
|
|
|
|
|
return Result { SQLCommand::Unknown, SQLErrorCode::InvalidNumberOfPlaceholderValues };
|
|
|
|
|
return context.placeholder_values[parameter_index()];
|
|
|
|
|
}
|
|
|
|
|
|
2022-02-10 07:46:36 -05:00
|
|
|
ResultOr<Value> NestedExpression::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
|
|
|
{
|
|
|
|
|
return expression()->evaluate(context);
|
|
|
|
|
}
|
|
|
|
|
|
2022-02-10 07:46:36 -05:00
|
|
|
ResultOr<Value> ChainedExpression::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
|
|
|
{
|
|
|
|
|
Vector<Value> values;
|
2022-09-21 13:47:02 -04:00
|
|
|
TRY(values.try_ensure_capacity(expressions().size()));
|
|
|
|
|
|
2022-02-10 07:46:36 -05:00
|
|
|
for (auto& expression : expressions())
|
2022-09-21 13:47:02 -04:00
|
|
|
values.unchecked_append(TRY(expression.evaluate(context)));
|
|
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
return Value::create_tuple(move(values));
|
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
|
|
|
}
|
|
|
|
|
|
2022-02-10 07:46:36 -05:00
|
|
|
ResultOr<Value> BinaryOperatorExpression::evaluate(ExecutionContext& context) const
|
2021-10-21 18:10:25 -04:00
|
|
|
{
|
2022-02-10 07:46:36 -05:00
|
|
|
Value lhs_value = TRY(lhs()->evaluate(context));
|
|
|
|
|
Value rhs_value = TRY(rhs()->evaluate(context));
|
|
|
|
|
|
2021-10-21 18:10:25 -04:00
|
|
|
switch (type()) {
|
|
|
|
|
case BinaryOperator::Concatenate: {
|
2022-02-10 07:46:36 -05:00
|
|
|
if (lhs_value.type() != SQLType::Text)
|
|
|
|
|
return Result { SQLCommand::Unknown, SQLErrorCode::BooleanOperatorTypeMismatch, BinaryOperator_name(type()) };
|
|
|
|
|
|
2021-10-21 18:10:25 -04:00
|
|
|
AK::StringBuilder builder;
|
2022-12-06 01:12:49 +00:00
|
|
|
builder.append(lhs_value.to_deprecated_string());
|
|
|
|
|
builder.append(rhs_value.to_deprecated_string());
|
|
|
|
|
return Value(builder.to_deprecated_string());
|
2021-10-21 18:10:25 -04:00
|
|
|
}
|
|
|
|
|
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();
|
2022-02-10 07:46:36 -05:00
|
|
|
if (!lhs_bool_maybe.has_value() || !rhs_bool_maybe.has_value())
|
|
|
|
|
return Result { SQLCommand::Unknown, SQLErrorCode::BooleanOperatorTypeMismatch, BinaryOperator_name(type()) };
|
|
|
|
|
|
2021-11-05 19:05:59 -04:00
|
|
|
return Value(lhs_bool_maybe.release_value() && rhs_bool_maybe.release_value());
|
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();
|
2022-02-10 07:46:36 -05:00
|
|
|
if (!lhs_bool_maybe.has_value() || !rhs_bool_maybe.has_value())
|
|
|
|
|
return Result { SQLCommand::Unknown, SQLErrorCode::BooleanOperatorTypeMismatch, BinaryOperator_name(type()) };
|
|
|
|
|
|
2021-11-05 19:05:59 -04:00
|
|
|
return Value(lhs_bool_maybe.release_value() || rhs_bool_maybe.release_value());
|
2021-10-21 18:10:25 -04:00
|
|
|
}
|
2021-10-23 10:46:33 -04:00
|
|
|
default:
|
|
|
|
|
VERIFY_NOT_REACHED();
|
2021-10-21 18:10:25 -04:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2022-02-10 07:46:36 -05:00
|
|
|
ResultOr<Value> UnaryOperatorExpression::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
|
|
|
{
|
2022-02-10 07:46:36 -05:00
|
|
|
Value expression_value = TRY(NestedExpression::evaluate(context));
|
|
|
|
|
|
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
|
|
|
switch (type()) {
|
|
|
|
|
case UnaryOperator::Plus:
|
|
|
|
|
if (expression_value.type() == SQLType::Integer || expression_value.type() == SQLType::Float)
|
|
|
|
|
return expression_value;
|
2022-02-10 07:46:36 -05:00
|
|
|
return Result { SQLCommand::Unknown, SQLErrorCode::NumericOperatorTypeMismatch, UnaryOperator_name(type()) };
|
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) {
|
2022-09-22 08:35:47 -04:00
|
|
|
expression_value = -expression_value.to_int().value();
|
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_value;
|
|
|
|
|
}
|
|
|
|
|
if (expression_value.type() == SQLType::Float) {
|
2022-09-22 08:35:47 -04:00
|
|
|
expression_value = -expression_value.to_double().value();
|
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_value;
|
|
|
|
|
}
|
2022-02-10 07:46:36 -05:00
|
|
|
return Result { SQLCommand::Unknown, SQLErrorCode::NumericOperatorTypeMismatch, UnaryOperator_name(type()) };
|
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) {
|
2022-09-22 08:35:47 -04:00
|
|
|
expression_value = !expression_value.to_bool().value();
|
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_value;
|
|
|
|
|
}
|
2022-02-10 07:46:36 -05:00
|
|
|
return Result { SQLCommand::Unknown, SQLErrorCode::BooleanOperatorTypeMismatch, UnaryOperator_name(type()) };
|
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) {
|
2022-09-22 08:35:47 -04:00
|
|
|
expression_value = ~expression_value.to_u32().value();
|
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_value;
|
|
|
|
|
}
|
2022-02-10 07:46:36 -05:00
|
|
|
return Result { SQLCommand::Unknown, SQLErrorCode::IntegerOperatorTypeMismatch, UnaryOperator_name(type()) };
|
|
|
|
|
default:
|
|
|
|
|
VERIFY_NOT_REACHED();
|
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
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2022-02-10 07:46:36 -05:00
|
|
|
ResultOr<Value> ColumnNameExpression::evaluate(ExecutionContext& context) const
|
2021-09-16 22:29:19 +02:00
|
|
|
{
|
2022-02-10 07:46:36 -05:00
|
|
|
if (!context.current_row)
|
|
|
|
|
return Result { SQLCommand::Unknown, SQLErrorCode::SyntaxError, column_name() };
|
|
|
|
|
|
2021-09-16 22:29:19 +02:00
|
|
|
auto& descriptor = *context.current_row->descriptor();
|
|
|
|
|
VERIFY(context.current_row->size() == descriptor.size());
|
2021-11-02 16:49:54 -04:00
|
|
|
Optional<size_t> index_in_row;
|
2021-09-16 22:29:19 +02:00
|
|
|
for (auto ix = 0u; ix < context.current_row->size(); ix++) {
|
|
|
|
|
auto& column_descriptor = descriptor[ix];
|
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()) {
|
2022-02-10 07:46:36 -05:00
|
|
|
if (index_in_row.has_value())
|
|
|
|
|
return Result { SQLCommand::Unknown, SQLErrorCode::AmbiguousColumnName, column_name() };
|
|
|
|
|
|
2021-11-02 16:49:54 -04:00
|
|
|
index_in_row = ix;
|
|
|
|
|
}
|
2021-09-16 22:29:19 +02:00
|
|
|
}
|
2021-11-02 16:49:54 -04:00
|
|
|
if (index_in_row.has_value())
|
|
|
|
|
return (*context.current_row)[index_in_row.value()];
|
2022-02-10 07:46:36 -05:00
|
|
|
|
|
|
|
|
return Result { SQLCommand::Unknown, SQLErrorCode::ColumnDoesNotExist, column_name() };
|
2021-09-16 22:29:19 +02:00
|
|
|
}
|
|
|
|
|
|
2022-02-10 07:46:36 -05:00
|
|
|
ResultOr<Value> MatchExpression::evaluate(ExecutionContext& context) const
|
2021-12-29 11:47:29 -03:00
|
|
|
{
|
|
|
|
|
switch (type()) {
|
|
|
|
|
case MatchOperator::Like: {
|
2022-02-10 07:46:36 -05:00
|
|
|
Value lhs_value = TRY(lhs()->evaluate(context));
|
|
|
|
|
Value rhs_value = TRY(rhs()->evaluate(context));
|
|
|
|
|
|
2021-12-29 11:47:29 -03:00
|
|
|
char escape_char = '\0';
|
|
|
|
|
if (escape()) {
|
2022-12-06 01:12:49 +00:00
|
|
|
auto escape_str = TRY(escape()->evaluate(context)).to_deprecated_string();
|
2022-02-10 07:46:36 -05:00
|
|
|
if (escape_str.length() != 1)
|
|
|
|
|
return Result { SQLCommand::Unknown, SQLErrorCode::SyntaxError, "ESCAPE should be a single character" };
|
2021-12-29 11:47:29 -03:00
|
|
|
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('^');
|
2022-12-06 01:12:49 +00:00
|
|
|
for (auto c : rhs_value.to_deprecated_string()) {
|
2021-12-29 11:47:29 -03:00
|
|
|
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) {
|
2022-07-11 17:32:29 +00:00
|
|
|
builder.append(".*"sv);
|
2021-12-29 11:47:29 -03:00
|
|
|
} else {
|
|
|
|
|
escaped = false;
|
|
|
|
|
builder.append(c);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
builder.append('$');
|
2022-02-10 07:46:36 -05:00
|
|
|
|
2021-12-29 11:47:29 -03:00
|
|
|
// FIXME: We should probably cache this regex.
|
|
|
|
|
auto regex = Regex<PosixBasic>(builder.build());
|
2022-12-06 01:12:49 +00:00
|
|
|
auto result = regex.match(lhs_value.to_deprecated_string(), PosixFlags::Insensitive | PosixFlags::Unicode);
|
2021-12-29 11:47:29 -03:00
|
|
|
return Value(invert_expression() ? !result.success : result.success);
|
|
|
|
|
}
|
2022-01-22 15:43:30 +01:00
|
|
|
case MatchOperator::Regexp: {
|
2022-02-10 07:46:36 -05:00
|
|
|
Value lhs_value = TRY(lhs()->evaluate(context));
|
|
|
|
|
Value rhs_value = TRY(rhs()->evaluate(context));
|
2022-01-22 15:43:30 +01:00
|
|
|
|
2022-12-06 01:12:49 +00:00
|
|
|
auto regex = Regex<PosixExtended>(rhs_value.to_deprecated_string());
|
2022-01-22 15:43:30 +01:00
|
|
|
auto err = regex.parser_result.error;
|
|
|
|
|
if (err != regex::Error::NoError) {
|
|
|
|
|
StringBuilder builder;
|
2022-07-11 17:32:29 +00:00
|
|
|
builder.append("Regular expression: "sv);
|
2022-01-22 15:43:30 +01:00
|
|
|
builder.append(get_error_string(err));
|
|
|
|
|
|
2022-02-10 07:46:36 -05:00
|
|
|
return Result { SQLCommand::Unknown, SQLErrorCode::SyntaxError, builder.build() };
|
2022-01-22 15:43:30 +01:00
|
|
|
}
|
|
|
|
|
|
2022-12-06 01:12:49 +00:00
|
|
|
auto result = regex.match(lhs_value.to_deprecated_string(), PosixFlags::Insensitive | PosixFlags::Unicode);
|
2022-01-22 15:43:30 +01:00
|
|
|
return Value(invert_expression() ? !result.success : result.success);
|
|
|
|
|
}
|
2021-12-29 11:47:29 -03:00
|
|
|
case MatchOperator::Glob:
|
2022-02-10 08:15:18 -05:00
|
|
|
return Result { SQLCommand::Unknown, SQLErrorCode::NotYetImplemented, "GLOB expression is not yet implemented"sv };
|
2021-12-29 11:47:29 -03:00
|
|
|
case MatchOperator::Match:
|
2022-02-10 08:15:18 -05:00
|
|
|
return Result { SQLCommand::Unknown, SQLErrorCode::NotYetImplemented, "MATCH expression is not yet implemented"sv };
|
2021-12-29 11:47:29 -03:00
|
|
|
default:
|
|
|
|
|
VERIFY_NOT_REACHED();
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
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
|
|
|
}
|