mirrors/ladybird
1
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-01-23 17:52:26 -05:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Tests/LibSQL/TestSqlStatementExecution.cpp

633 lines
24 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>
LibSQL: Implement DESCRIBE TABLE tests
2021-09-19 21:35:16 +02:00
* Copyright (c) 2021, Mahmoud Mandour <ma.mandourr@gmail.com>
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
*/
#include <unistd.h>
#include <AK/ScopeGuard.h>
#include <LibSQL/AST/Parser.h>
#include <LibSQL/Database.h>
LibSQL+SQLServer: Move LibSQL/SQLResult.[h,cpp] to LibSQL/Result.[h,cpp] Rename the file to match the new class name.
2022-02-09 16:02:49 -05:00
#include <LibSQL/Result.h>
LibSQL+SQLServer: Introduce and use ResultOr<ValueType> The result of a SQL statement execution is either: 1. An error. 2. The list of rows inserted, deleted, selected, etc. (2) is currently represented by a combination of the Result class and the ResultSet list it holds. This worked okay, but issues start to arise when trying to use Result in non-statement contexts (for example, when introducing Result to SQL expression execution). What we really need is for Result to be a thin wrapper that represents both (1) and (2), and to not have any explicit members like a ResultSet. So this commit removes ResultSet from Result, and introduces ResultOr, which is just an alias for AK::ErrorOrr. Statement execution now returns ResultOr<ResultSet> instead of Result. This further opens the door for expression execution to return ResultOr<Value> in the future. Lastly, this moves some other context held by Result over to ResultSet. This includes the row count (which is really just the size of ResultSet) and the command for which the result is for.
2022-02-10 14:43:00 -05:00
#include <LibSQL/ResultSet.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/Row.h>
#include <LibSQL/Value.h>
#include <LibTest/TestCase.h>
namespace {
constexpr const char* db_name = "/tmp/test.db";
LibSQL+SQLServer: Introduce and use ResultOr<ValueType> The result of a SQL statement execution is either: 1. An error. 2. The list of rows inserted, deleted, selected, etc. (2) is currently represented by a combination of the Result class and the ResultSet list it holds. This worked okay, but issues start to arise when trying to use Result in non-statement contexts (for example, when introducing Result to SQL expression execution). What we really need is for Result to be a thin wrapper that represents both (1) and (2), and to not have any explicit members like a ResultSet. So this commit removes ResultSet from Result, and introduces ResultOr, which is just an alias for AK::ErrorOrr. Statement execution now returns ResultOr<ResultSet> instead of Result. This further opens the door for expression execution to return ResultOr<Value> in the future. Lastly, this moves some other context held by Result over to ResultSet. This includes the row count (which is really just the size of ResultSet) and the command for which the result is for.
2022-02-10 14:43:00 -05:00
SQL::ResultOr<SQL::ResultSet> try_execute(NonnullRefPtr<SQL::Database> database, String const& sql)
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
{
auto parser = SQL::AST::Parser(SQL::AST::Lexer(sql));
auto statement = parser.next_statement();
EXPECT(!parser.has_errors());
LibSQL Tests: Add tests for `SELECT ... WHERE ...`
2021-10-23 10:47:12 -04:00
if (parser.has_errors())
Everywhere: Fix format-vulnerabilities Command used: grep -Pirn '(out|warn)ln\((?!["\)]|format,|stderr,|stdout,|output, ")' \ AK Kernel/ Tests/ Userland/ (Plus some manual reviewing.) Let's pick ArgsParser as an example: outln(file, m_general_help); This will fail at runtime if the general help happens to contain braces. Even if this transformation turns out to be unnecessary in a place or two, this way the code is "more obviously" correct.
2021-09-09 17:06:15 +02:00
outln("{}", parser.errors()[0].to_string());
LibSQL+SQLServer: Introduce and use ResultOr<ValueType> The result of a SQL statement execution is either: 1. An error. 2. The list of rows inserted, deleted, selected, etc. (2) is currently represented by a combination of the Result class and the ResultSet list it holds. This worked okay, but issues start to arise when trying to use Result in non-statement contexts (for example, when introducing Result to SQL expression execution). What we really need is for Result to be a thin wrapper that represents both (1) and (2), and to not have any explicit members like a ResultSet. So this commit removes ResultSet from Result, and introduces ResultOr, which is just an alias for AK::ErrorOrr. Statement execution now returns ResultOr<ResultSet> instead of Result. This further opens the door for expression execution to return ResultOr<Value> in the future. Lastly, this moves some other context held by Result over to ResultSet. This includes the row count (which is really just the size of ResultSet) and the command for which the result is for.
2022-02-10 14:43:00 -05:00
return statement->execute(move(database));
}
SQL::ResultSet execute(NonnullRefPtr<SQL::Database> database, String const& sql)
{
auto result = try_execute(move(database), sql);
if (result.is_error()) {
outln("{}", result.release_error().error_string());
VERIFY_NOT_REACHED();
}
return result.release_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
}
void create_schema(NonnullRefPtr<SQL::Database> database)
{
auto result = execute(database, "CREATE SCHEMA TestSchema;");
LibSQL+SQLServer: Introduce and use ResultOr<ValueType> The result of a SQL statement execution is either: 1. An error. 2. The list of rows inserted, deleted, selected, etc. (2) is currently represented by a combination of the Result class and the ResultSet list it holds. This worked okay, but issues start to arise when trying to use Result in non-statement contexts (for example, when introducing Result to SQL expression execution). What we really need is for Result to be a thin wrapper that represents both (1) and (2), and to not have any explicit members like a ResultSet. So this commit removes ResultSet from Result, and introduces ResultOr, which is just an alias for AK::ErrorOrr. Statement execution now returns ResultOr<ResultSet> instead of Result. This further opens the door for expression execution to return ResultOr<Value> in the future. Lastly, this moves some other context held by Result over to ResultSet. This includes the row count (which is really just the size of ResultSet) and the command for which the result is for.
2022-02-10 14:43:00 -05:00
EXPECT_EQ(result.command(), SQL::SQLCommand::Create);
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
}
void create_table(NonnullRefPtr<SQL::Database> database)
{
create_schema(database);
auto result = execute(database, "CREATE TABLE TestSchema.TestTable ( TextColumn text, IntColumn integer );");
LibSQL+SQLServer: Introduce and use ResultOr<ValueType> The result of a SQL statement execution is either: 1. An error. 2. The list of rows inserted, deleted, selected, etc. (2) is currently represented by a combination of the Result class and the ResultSet list it holds. This worked okay, but issues start to arise when trying to use Result in non-statement contexts (for example, when introducing Result to SQL expression execution). What we really need is for Result to be a thin wrapper that represents both (1) and (2), and to not have any explicit members like a ResultSet. So this commit removes ResultSet from Result, and introduces ResultOr, which is just an alias for AK::ErrorOrr. Statement execution now returns ResultOr<ResultSet> instead of Result. This further opens the door for expression execution to return ResultOr<Value> in the future. Lastly, this moves some other context held by Result over to ResultSet. This includes the row count (which is really just the size of ResultSet) and the command for which the result is for.
2022-02-10 14:43:00 -05:00
EXPECT_EQ(result.command(), SQL::SQLCommand::Create);
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: 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
void create_two_tables(NonnullRefPtr<SQL::Database> database)
{
create_schema(database);
auto result = execute(database, "CREATE TABLE TestSchema.TestTable1 ( TextColumn1 text, IntColumn integer );");
LibSQL+SQLServer: Introduce and use ResultOr<ValueType> The result of a SQL statement execution is either: 1. An error. 2. The list of rows inserted, deleted, selected, etc. (2) is currently represented by a combination of the Result class and the ResultSet list it holds. This worked okay, but issues start to arise when trying to use Result in non-statement contexts (for example, when introducing Result to SQL expression execution). What we really need is for Result to be a thin wrapper that represents both (1) and (2), and to not have any explicit members like a ResultSet. So this commit removes ResultSet from Result, and introduces ResultOr, which is just an alias for AK::ErrorOrr. Statement execution now returns ResultOr<ResultSet> instead of Result. This further opens the door for expression execution to return ResultOr<Value> in the future. Lastly, this moves some other context held by Result over to ResultSet. This includes the row count (which is really just the size of ResultSet) and the command for which the result is for.
2022-02-10 14:43:00 -05:00
EXPECT_EQ(result.command(), SQL::SQLCommand::Create);
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
result = execute(database, "CREATE TABLE TestSchema.TestTable2 ( TextColumn2 text, IntColumn integer );");
LibSQL+SQLServer: Introduce and use ResultOr<ValueType> The result of a SQL statement execution is either: 1. An error. 2. The list of rows inserted, deleted, selected, etc. (2) is currently represented by a combination of the Result class and the ResultSet list it holds. This worked okay, but issues start to arise when trying to use Result in non-statement contexts (for example, when introducing Result to SQL expression execution). What we really need is for Result to be a thin wrapper that represents both (1) and (2), and to not have any explicit members like a ResultSet. So this commit removes ResultSet from Result, and introduces ResultOr, which is just an alias for AK::ErrorOrr. Statement execution now returns ResultOr<ResultSet> instead of Result. This further opens the door for expression execution to return ResultOr<Value> in the future. Lastly, this moves some other context held by Result over to ResultSet. This includes the row count (which is really just the size of ResultSet) and the command for which the result is for.
2022-02-10 14:43:00 -05:00
EXPECT_EQ(result.command(), SQL::SQLCommand::Create);
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
}
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
TEST_CASE(create_schema)
{
ScopeGuard guard([]() { unlink(db_name); });
auto database = SQL::Database::construct(db_name);
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
EXPECT(!database->open().is_error());
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
create_schema(database);
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
auto schema_or_error = database->get_schema("TESTSCHEMA");
EXPECT(!schema_or_error.is_error());
EXPECT(schema_or_error.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
}
TEST_CASE(create_table)
{
ScopeGuard guard([]() { unlink(db_name); });
auto database = SQL::Database::construct(db_name);
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
EXPECT(!database->open().is_error());
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
create_table(database);
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
auto table_or_error = database->get_table("TESTSCHEMA", "TESTTABLE");
EXPECT(!table_or_error.is_error());
EXPECT(table_or_error.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
}
TEST_CASE(insert_into_table)
{
ScopeGuard guard([]() { unlink(db_name); });
auto database = SQL::Database::construct(db_name);
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
EXPECT(!database->open().is_error());
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
create_table(database);
auto result = execute(database, "INSERT INTO TestSchema.TestTable ( TextColumn, IntColumn ) VALUES ( 'Test', 42 );");
LibSQL+SQLServer: Introduce and use ResultOr<ValueType> The result of a SQL statement execution is either: 1. An error. 2. The list of rows inserted, deleted, selected, etc. (2) is currently represented by a combination of the Result class and the ResultSet list it holds. This worked okay, but issues start to arise when trying to use Result in non-statement contexts (for example, when introducing Result to SQL expression execution). What we really need is for Result to be a thin wrapper that represents both (1) and (2), and to not have any explicit members like a ResultSet. So this commit removes ResultSet from Result, and introduces ResultOr, which is just an alias for AK::ErrorOrr. Statement execution now returns ResultOr<ResultSet> instead of Result. This further opens the door for expression execution to return ResultOr<Value> in the future. Lastly, this moves some other context held by Result over to ResultSet. This includes the row count (which is really just the size of ResultSet) and the command for which the result is for.
2022-02-10 14:43:00 -05:00
EXPECT(result.size() == 1);
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: 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
auto table_or_error = database->get_table("TESTSCHEMA", "TESTTABLE");
EXPECT(!table_or_error.is_error());
auto table = table_or_error.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
int count = 0;
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
auto rows_or_error = database->select_all(*table);
EXPECT(!rows_or_error.is_error());
for (auto& row : rows_or_error.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
EXPECT_EQ(row["TEXTCOLUMN"].to_string(), "Test");
EXPECT_EQ(row["INTCOLUMN"].to_int().value(), 42);
count++;
}
EXPECT_EQ(count, 1);
}
LibSQL: Test INSERT statement with wrong data types
2021-09-17 20:48:54 +02:00
TEST_CASE(insert_into_table_wrong_data_types)
{
ScopeGuard guard([]() { unlink(db_name); });
auto database = SQL::Database::construct(db_name);
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
EXPECT(!database->open().is_error());
LibSQL: Test INSERT statement with wrong data types
2021-09-17 20:48:54 +02:00
create_table(database);
LibSQL+SQLServer: Introduce and use ResultOr<ValueType> The result of a SQL statement execution is either: 1. An error. 2. The list of rows inserted, deleted, selected, etc. (2) is currently represented by a combination of the Result class and the ResultSet list it holds. This worked okay, but issues start to arise when trying to use Result in non-statement contexts (for example, when introducing Result to SQL expression execution). What we really need is for Result to be a thin wrapper that represents both (1) and (2), and to not have any explicit members like a ResultSet. So this commit removes ResultSet from Result, and introduces ResultOr, which is just an alias for AK::ErrorOrr. Statement execution now returns ResultOr<ResultSet> instead of Result. This further opens the door for expression execution to return ResultOr<Value> in the future. Lastly, this moves some other context held by Result over to ResultSet. This includes the row count (which is really just the size of ResultSet) and the command for which the result is for.
2022-02-10 14:43:00 -05:00
auto result = try_execute(database, "INSERT INTO TestSchema.TestTable ( TextColumn, IntColumn ) VALUES (43, 'Test_2');");
EXPECT(result.is_error());
EXPECT(result.release_error().error() == SQL::SQLErrorCode::InvalidValueType);
LibSQL: Test INSERT statement with wrong data types
2021-09-17 20:48:54 +02:00
}
TEST_CASE(insert_into_table_multiple_tuples_wrong_data_types)
{
ScopeGuard guard([]() { unlink(db_name); });
auto database = SQL::Database::construct(db_name);
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
EXPECT(!database->open().is_error());
LibSQL: Test INSERT statement with wrong data types
2021-09-17 20:48:54 +02:00
create_table(database);
LibSQL+SQLServer: Introduce and use ResultOr<ValueType> The result of a SQL statement execution is either: 1. An error. 2. The list of rows inserted, deleted, selected, etc. (2) is currently represented by a combination of the Result class and the ResultSet list it holds. This worked okay, but issues start to arise when trying to use Result in non-statement contexts (for example, when introducing Result to SQL expression execution). What we really need is for Result to be a thin wrapper that represents both (1) and (2), and to not have any explicit members like a ResultSet. So this commit removes ResultSet from Result, and introduces ResultOr, which is just an alias for AK::ErrorOrr. Statement execution now returns ResultOr<ResultSet> instead of Result. This further opens the door for expression execution to return ResultOr<Value> in the future. Lastly, this moves some other context held by Result over to ResultSet. This includes the row count (which is really just the size of ResultSet) and the command for which the result is for.
2022-02-10 14:43:00 -05:00
auto result = try_execute(database, "INSERT INTO TestSchema.TestTable ( TextColumn, IntColumn ) VALUES ('Test_1', 42), (43, 'Test_2');");
EXPECT(result.is_error());
EXPECT(result.release_error().error() == SQL::SQLErrorCode::InvalidValueType);
LibSQL: Test INSERT statement with wrong data types
2021-09-17 20:48:54 +02:00
}
LibSQL: Test INSERT statement with wrong number of values
2021-09-17 20:49:49 +02:00
TEST_CASE(insert_wrong_number_of_values)
{
ScopeGuard guard([]() { unlink(db_name); });
auto database = SQL::Database::construct(db_name);
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
EXPECT(!database->open().is_error());
LibSQL: Test INSERT statement with wrong number of values
2021-09-17 20:49:49 +02:00
create_table(database);
LibSQL+SQLServer: Introduce and use ResultOr<ValueType> The result of a SQL statement execution is either: 1. An error. 2. The list of rows inserted, deleted, selected, etc. (2) is currently represented by a combination of the Result class and the ResultSet list it holds. This worked okay, but issues start to arise when trying to use Result in non-statement contexts (for example, when introducing Result to SQL expression execution). What we really need is for Result to be a thin wrapper that represents both (1) and (2), and to not have any explicit members like a ResultSet. So this commit removes ResultSet from Result, and introduces ResultOr, which is just an alias for AK::ErrorOrr. Statement execution now returns ResultOr<ResultSet> instead of Result. This further opens the door for expression execution to return ResultOr<Value> in the future. Lastly, this moves some other context held by Result over to ResultSet. This includes the row count (which is really just the size of ResultSet) and the command for which the result is for.
2022-02-10 14:43:00 -05:00
auto result = try_execute(database, "INSERT INTO TestSchema.TestTable VALUES ( 42 );");
EXPECT(result.is_error());
EXPECT(result.release_error().error() == SQL::SQLErrorCode::InvalidNumberOfValues);
LibSQL: Test INSERT statement with wrong number of values
2021-09-17 20:49:49 +02:00
}
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
TEST_CASE(insert_identifier_as_value)
{
ScopeGuard guard([]() { unlink(db_name); });
auto database = SQL::Database::construct(db_name);
EXPECT(!database->open().is_error());
create_table(database);
LibSQL+SQLServer: Introduce and use ResultOr<ValueType> The result of a SQL statement execution is either: 1. An error. 2. The list of rows inserted, deleted, selected, etc. (2) is currently represented by a combination of the Result class and the ResultSet list it holds. This worked okay, but issues start to arise when trying to use Result in non-statement contexts (for example, when introducing Result to SQL expression execution). What we really need is for Result to be a thin wrapper that represents both (1) and (2), and to not have any explicit members like a ResultSet. So this commit removes ResultSet from Result, and introduces ResultOr, which is just an alias for AK::ErrorOrr. Statement execution now returns ResultOr<ResultSet> instead of Result. This further opens the door for expression execution to return ResultOr<Value> in the future. Lastly, this moves some other context held by Result over to ResultSet. This includes the row count (which is really just the size of ResultSet) and the command for which the result is for.
2022-02-10 14:43:00 -05:00
auto result = try_execute(database, "INSERT INTO TestSchema.TestTable VALUES ( identifier, 42 );");
EXPECT(result.is_error());
EXPECT(result.release_error().error() == SQL::SQLErrorCode::SyntaxError);
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
}
TEST_CASE(insert_quoted_identifier_as_value)
{
ScopeGuard guard([]() { unlink(db_name); });
auto database = SQL::Database::construct(db_name);
EXPECT(!database->open().is_error());
create_table(database);
LibSQL+SQLServer: Introduce and use ResultOr<ValueType> The result of a SQL statement execution is either: 1. An error. 2. The list of rows inserted, deleted, selected, etc. (2) is currently represented by a combination of the Result class and the ResultSet list it holds. This worked okay, but issues start to arise when trying to use Result in non-statement contexts (for example, when introducing Result to SQL expression execution). What we really need is for Result to be a thin wrapper that represents both (1) and (2), and to not have any explicit members like a ResultSet. So this commit removes ResultSet from Result, and introduces ResultOr, which is just an alias for AK::ErrorOrr. Statement execution now returns ResultOr<ResultSet> instead of Result. This further opens the door for expression execution to return ResultOr<Value> in the future. Lastly, this moves some other context held by Result over to ResultSet. This includes the row count (which is really just the size of ResultSet) and the command for which the result is for.
2022-02-10 14:43:00 -05:00
auto result = try_execute(database, "INSERT INTO TestSchema.TestTable VALUES ( \"QuotedIdentifier\", 42 );");
EXPECT(result.is_error());
EXPECT(result.release_error().error() == SQL::SQLErrorCode::SyntaxError);
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
}
LibSQL: Add an INSERT without column names test This adds a passing test of an insert statement that contains no column names and assumes full tuple input
2021-09-17 23:29:28 +02:00
TEST_CASE(insert_without_column_names)
{
ScopeGuard guard([]() { unlink(db_name); });
auto database = SQL::Database::construct(db_name);
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
EXPECT(!database->open().is_error());
LibSQL: Add an INSERT without column names test This adds a passing test of an insert statement that contains no column names and assumes full tuple input
2021-09-17 23:29:28 +02:00
create_table(database);
auto result = execute(database, "INSERT INTO TestSchema.TestTable VALUES ('Test_1', 42), ('Test_2', 43);");
LibSQL+SQLServer: Introduce and use ResultOr<ValueType> The result of a SQL statement execution is either: 1. An error. 2. The list of rows inserted, deleted, selected, etc. (2) is currently represented by a combination of the Result class and the ResultSet list it holds. This worked okay, but issues start to arise when trying to use Result in non-statement contexts (for example, when introducing Result to SQL expression execution). What we really need is for Result to be a thin wrapper that represents both (1) and (2), and to not have any explicit members like a ResultSet. So this commit removes ResultSet from Result, and introduces ResultOr, which is just an alias for AK::ErrorOrr. Statement execution now returns ResultOr<ResultSet> instead of Result. This further opens the door for expression execution to return ResultOr<Value> in the future. Lastly, this moves some other context held by Result over to ResultSet. This includes the row count (which is really just the size of ResultSet) and the command for which the result is for.
2022-02-10 14:43:00 -05:00
EXPECT(result.size() == 2);
LibSQL: Add an INSERT without column names test This adds a passing test of an insert statement that contains no column names and assumes full tuple input
2021-09-17 23:29:28 +02: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
auto table_or_error = database->get_table("TESTSCHEMA", "TESTTABLE");
EXPECT(!table_or_error.is_error());
auto rows_or_error = database->select_all(*(table_or_error.value()));
EXPECT(!rows_or_error.is_error());
EXPECT_EQ(rows_or_error.value().size(), 2u);
LibSQL: Add an INSERT without column names test This adds a passing test of an insert statement that contains no column names and assumes full tuple input
2021-09-17 23:29:28 +02:00
}
LibSQL: Do not crash when SELECTing from an empty table The crash was caused by getting the first element of an empty vector.
2022-02-09 17:10:08 -05:00
TEST_CASE(select_from_empty_table)
{
ScopeGuard guard([]() { unlink(db_name); });
auto database = SQL::Database::construct(db_name);
EXPECT(!database->open().is_error());
create_table(database);
auto result = execute(database, "SELECT * FROM TestSchema.TestTable;");
LibSQL+SQLServer: Introduce and use ResultOr<ValueType> The result of a SQL statement execution is either: 1. An error. 2. The list of rows inserted, deleted, selected, etc. (2) is currently represented by a combination of the Result class and the ResultSet list it holds. This worked okay, but issues start to arise when trying to use Result in non-statement contexts (for example, when introducing Result to SQL expression execution). What we really need is for Result to be a thin wrapper that represents both (1) and (2), and to not have any explicit members like a ResultSet. So this commit removes ResultSet from Result, and introduces ResultOr, which is just an alias for AK::ErrorOrr. Statement execution now returns ResultOr<ResultSet> instead of Result. This further opens the door for expression execution to return ResultOr<Value> in the future. Lastly, this moves some other context held by Result over to ResultSet. This includes the row count (which is really just the size of ResultSet) and the command for which the result is for.
2022-02-10 14:43:00 -05:00
EXPECT(result.is_empty());
LibSQL: Do not crash when SELECTing from an empty table The crash was caused by getting the first element of an empty vector.
2022-02-09 17:10:08 -05: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
TEST_CASE(select_from_table)
{
ScopeGuard guard([]() { unlink(db_name); });
auto database = SQL::Database::construct(db_name);
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
EXPECT(!database->open().is_error());
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
create_table(database);
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
auto result = execute(database,
"INSERT INTO TestSchema.TestTable ( TextColumn, IntColumn ) VALUES "
"( 'Test_1', 42 ), "
"( 'Test_2', 43 ), "
"( 'Test_3', 44 ), "
"( 'Test_4', 45 ), "
"( 'Test_5', 46 );");
LibSQL+SQLServer: Introduce and use ResultOr<ValueType> The result of a SQL statement execution is either: 1. An error. 2. The list of rows inserted, deleted, selected, etc. (2) is currently represented by a combination of the Result class and the ResultSet list it holds. This worked okay, but issues start to arise when trying to use Result in non-statement contexts (for example, when introducing Result to SQL expression execution). What we really need is for Result to be a thin wrapper that represents both (1) and (2), and to not have any explicit members like a ResultSet. So this commit removes ResultSet from Result, and introduces ResultOr, which is just an alias for AK::ErrorOrr. Statement execution now returns ResultOr<ResultSet> instead of Result. This further opens the door for expression execution to return ResultOr<Value> in the future. Lastly, this moves some other context held by Result over to ResultSet. This includes the row count (which is really just the size of ResultSet) and the command for which the result is for.
2022-02-10 14:43:00 -05:00
EXPECT(result.size() == 5);
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
result = execute(database, "SELECT * FROM TestSchema.TestTable;");
LibSQL+SQLServer: Introduce and use ResultOr<ValueType> The result of a SQL statement execution is either: 1. An error. 2. The list of rows inserted, deleted, selected, etc. (2) is currently represented by a combination of the Result class and the ResultSet list it holds. This worked okay, but issues start to arise when trying to use Result in non-statement contexts (for example, when introducing Result to SQL expression execution). What we really need is for Result to be a thin wrapper that represents both (1) and (2), and to not have any explicit members like a ResultSet. So this commit removes ResultSet from Result, and introduces ResultOr, which is just an alias for AK::ErrorOrr. Statement execution now returns ResultOr<ResultSet> instead of Result. This further opens the door for expression execution to return ResultOr<Value> in the future. Lastly, this moves some other context held by Result over to ResultSet. This includes the row count (which is really just the size of ResultSet) and the command for which the result is for.
2022-02-10 14:43:00 -05:00
EXPECT_EQ(result.size(), 5u);
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 Tests: Add tests for `SELECT ... WHERE ...`
2021-10-23 10:47:12 -04:00
TEST_CASE(select_with_column_names)
{
ScopeGuard guard([]() { unlink(db_name); });
auto database = SQL::Database::construct(db_name);
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
EXPECT(!database->open().is_error());
LibSQL Tests: Add tests for `SELECT ... WHERE ...`
2021-10-23 10:47:12 -04:00
create_table(database);
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
auto result = execute(database,
"INSERT INTO TestSchema.TestTable ( TextColumn, IntColumn ) VALUES "
"( 'Test_1', 42 ), "
"( 'Test_2', 43 ), "
"( 'Test_3', 44 ), "
"( 'Test_4', 45 ), "
"( 'Test_5', 46 );");
LibSQL+SQLServer: Introduce and use ResultOr<ValueType> The result of a SQL statement execution is either: 1. An error. 2. The list of rows inserted, deleted, selected, etc. (2) is currently represented by a combination of the Result class and the ResultSet list it holds. This worked okay, but issues start to arise when trying to use Result in non-statement contexts (for example, when introducing Result to SQL expression execution). What we really need is for Result to be a thin wrapper that represents both (1) and (2), and to not have any explicit members like a ResultSet. So this commit removes ResultSet from Result, and introduces ResultOr, which is just an alias for AK::ErrorOrr. Statement execution now returns ResultOr<ResultSet> instead of Result. This further opens the door for expression execution to return ResultOr<Value> in the future. Lastly, this moves some other context held by Result over to ResultSet. This includes the row count (which is really just the size of ResultSet) and the command for which the result is for.
2022-02-10 14:43:00 -05:00
EXPECT(result.size() == 5);
LibSQL Tests: Add tests for `SELECT ... WHERE ...`
2021-10-23 10:47:12 -04:00
result = execute(database, "SELECT TextColumn FROM TestSchema.TestTable;");
LibSQL+SQLServer: Introduce and use ResultOr<ValueType> The result of a SQL statement execution is either: 1. An error. 2. The list of rows inserted, deleted, selected, etc. (2) is currently represented by a combination of the Result class and the ResultSet list it holds. This worked okay, but issues start to arise when trying to use Result in non-statement contexts (for example, when introducing Result to SQL expression execution). What we really need is for Result to be a thin wrapper that represents both (1) and (2), and to not have any explicit members like a ResultSet. So this commit removes ResultSet from Result, and introduces ResultOr, which is just an alias for AK::ErrorOrr. Statement execution now returns ResultOr<ResultSet> instead of Result. This further opens the door for expression execution to return ResultOr<Value> in the future. Lastly, this moves some other context held by Result over to ResultSet. This includes the row count (which is really just the size of ResultSet) and the command for which the result is for.
2022-02-10 14:43:00 -05:00
EXPECT_EQ(result.size(), 5u);
EXPECT_EQ(result[0].row.size(), 1u);
LibSQL Tests: Add tests for `SELECT ... WHERE ...`
2021-10-23 10:47:12 -04:00
}
TEST_CASE(select_with_nonexisting_column_name)
{
ScopeGuard guard([]() { unlink(db_name); });
auto database = SQL::Database::construct(db_name);
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
EXPECT(!database->open().is_error());
LibSQL Tests: Add tests for `SELECT ... WHERE ...`
2021-10-23 10:47:12 -04:00
create_table(database);
auto result = execute(database,
"INSERT INTO TestSchema.TestTable ( TextColumn, IntColumn ) VALUES "
"( 'Test_1', 42 ), "
"( 'Test_2', 43 ), "
"( 'Test_3', 44 ), "
"( 'Test_4', 45 ), "
"( 'Test_5', 46 );");
LibSQL+SQLServer: Introduce and use ResultOr<ValueType> The result of a SQL statement execution is either: 1. An error. 2. The list of rows inserted, deleted, selected, etc. (2) is currently represented by a combination of the Result class and the ResultSet list it holds. This worked okay, but issues start to arise when trying to use Result in non-statement contexts (for example, when introducing Result to SQL expression execution). What we really need is for Result to be a thin wrapper that represents both (1) and (2), and to not have any explicit members like a ResultSet. So this commit removes ResultSet from Result, and introduces ResultOr, which is just an alias for AK::ErrorOrr. Statement execution now returns ResultOr<ResultSet> instead of Result. This further opens the door for expression execution to return ResultOr<Value> in the future. Lastly, this moves some other context held by Result over to ResultSet. This includes the row count (which is really just the size of ResultSet) and the command for which the result is for.
2022-02-10 14:43:00 -05:00
EXPECT(result.size() == 5);
auto insert_result = try_execute(database, "SELECT Bogus FROM TestSchema.TestTable;");
EXPECT(insert_result.is_error());
EXPECT(insert_result.release_error().error() == SQL::SQLErrorCode::ColumnDoesNotExist);
LibSQL Tests: Add tests for `SELECT ... WHERE ...`
2021-10-23 10:47:12 -04:00
}
TEST_CASE(select_with_where)
{
ScopeGuard guard([]() { unlink(db_name); });
auto database = SQL::Database::construct(db_name);
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
EXPECT(!database->open().is_error());
LibSQL Tests: Add tests for `SELECT ... WHERE ...`
2021-10-23 10:47:12 -04:00
create_table(database);
auto result = execute(database,
"INSERT INTO TestSchema.TestTable ( TextColumn, IntColumn ) VALUES "
"( 'Test_1', 42 ), "
"( 'Test_2', 43 ), "
"( 'Test_3', 44 ), "
"( 'Test_4', 45 ), "
"( 'Test_5', 46 );");
LibSQL+SQLServer: Introduce and use ResultOr<ValueType> The result of a SQL statement execution is either: 1. An error. 2. The list of rows inserted, deleted, selected, etc. (2) is currently represented by a combination of the Result class and the ResultSet list it holds. This worked okay, but issues start to arise when trying to use Result in non-statement contexts (for example, when introducing Result to SQL expression execution). What we really need is for Result to be a thin wrapper that represents both (1) and (2), and to not have any explicit members like a ResultSet. So this commit removes ResultSet from Result, and introduces ResultOr, which is just an alias for AK::ErrorOrr. Statement execution now returns ResultOr<ResultSet> instead of Result. This further opens the door for expression execution to return ResultOr<Value> in the future. Lastly, this moves some other context held by Result over to ResultSet. This includes the row count (which is really just the size of ResultSet) and the command for which the result is for.
2022-02-10 14:43:00 -05:00
EXPECT(result.size() == 5);
LibSQL Tests: Add tests for `SELECT ... WHERE ...`
2021-10-23 10:47:12 -04:00
result = execute(database, "SELECT TextColumn, IntColumn FROM TestSchema.TestTable WHERE IntColumn > 44;");
LibSQL+SQLServer: Introduce and use ResultOr<ValueType> The result of a SQL statement execution is either: 1. An error. 2. The list of rows inserted, deleted, selected, etc. (2) is currently represented by a combination of the Result class and the ResultSet list it holds. This worked okay, but issues start to arise when trying to use Result in non-statement contexts (for example, when introducing Result to SQL expression execution). What we really need is for Result to be a thin wrapper that represents both (1) and (2), and to not have any explicit members like a ResultSet. So this commit removes ResultSet from Result, and introduces ResultOr, which is just an alias for AK::ErrorOrr. Statement execution now returns ResultOr<ResultSet> instead of Result. This further opens the door for expression execution to return ResultOr<Value> in the future. Lastly, this moves some other context held by Result over to ResultSet. This includes the row count (which is really just the size of ResultSet) and the command for which the result is for.
2022-02-10 14:43:00 -05:00
EXPECT_EQ(result.size(), 2u);
for (auto& row : result) {
LibSQL+SQLServer: Implement first cut of SELECT ... ORDER BY foo Ordering is done by replacing the straight Vector holding the query result in the SQLResult object with a dedicated Vector subclass that inserts result rows according to their sort key using a binary search. This is done in the ResultSet class. There are limitations: - "SELECT ... ORDER BY 1" (or 2 or 3 etc) is supposed to sort by the n-th result column. This doesn't work yet - "SELECT ... column-expression alias ... ORDER BY alias" is supposed to sort by the column with the given alias. This doesn't work yet What does work however is something like ```SELECT foo FROM bar SORT BY quux``` i.e. sorted by a column not in the result set. Once functions are supported it should be possible to sort by random functions.
2022-01-12 09:49:43 -05:00
EXPECT(row.row[1].to_int().value() > 44);
LibSQL Tests: Add tests for `SELECT ... WHERE ...`
2021-10-23 10:47:12 -04: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
TEST_CASE(select_cross_join)
{
ScopeGuard guard([]() { unlink(db_name); });
auto database = SQL::Database::construct(db_name);
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
EXPECT(!database->open().is_error());
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
create_two_tables(database);
auto result = execute(database,
"INSERT INTO TestSchema.TestTable1 ( TextColumn1, IntColumn ) VALUES "
"( 'Test_1', 42 ), "
"( 'Test_2', 43 ), "
"( 'Test_3', 44 ), "
"( 'Test_4', 45 ), "
"( 'Test_5', 46 );");
LibSQL+SQLServer: Introduce and use ResultOr<ValueType> The result of a SQL statement execution is either: 1. An error. 2. The list of rows inserted, deleted, selected, etc. (2) is currently represented by a combination of the Result class and the ResultSet list it holds. This worked okay, but issues start to arise when trying to use Result in non-statement contexts (for example, when introducing Result to SQL expression execution). What we really need is for Result to be a thin wrapper that represents both (1) and (2), and to not have any explicit members like a ResultSet. So this commit removes ResultSet from Result, and introduces ResultOr, which is just an alias for AK::ErrorOrr. Statement execution now returns ResultOr<ResultSet> instead of Result. This further opens the door for expression execution to return ResultOr<Value> in the future. Lastly, this moves some other context held by Result over to ResultSet. This includes the row count (which is really just the size of ResultSet) and the command for which the result is for.
2022-02-10 14:43:00 -05:00
EXPECT(result.size() == 5);
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
result = execute(database,
"INSERT INTO TestSchema.TestTable2 ( TextColumn2, IntColumn ) VALUES "
"( 'Test_10', 40 ), "
"( 'Test_11', 41 ), "
"( 'Test_12', 42 ), "
"( 'Test_13', 47 ), "
"( 'Test_14', 48 );");
LibSQL+SQLServer: Introduce and use ResultOr<ValueType> The result of a SQL statement execution is either: 1. An error. 2. The list of rows inserted, deleted, selected, etc. (2) is currently represented by a combination of the Result class and the ResultSet list it holds. This worked okay, but issues start to arise when trying to use Result in non-statement contexts (for example, when introducing Result to SQL expression execution). What we really need is for Result to be a thin wrapper that represents both (1) and (2), and to not have any explicit members like a ResultSet. So this commit removes ResultSet from Result, and introduces ResultOr, which is just an alias for AK::ErrorOrr. Statement execution now returns ResultOr<ResultSet> instead of Result. This further opens the door for expression execution to return ResultOr<Value> in the future. Lastly, this moves some other context held by Result over to ResultSet. This includes the row count (which is really just the size of ResultSet) and the command for which the result is for.
2022-02-10 14:43:00 -05:00
EXPECT(result.size() == 5);
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
result = execute(database, "SELECT * FROM TestSchema.TestTable1, TestSchema.TestTable2;");
LibSQL+SQLServer: Introduce and use ResultOr<ValueType> The result of a SQL statement execution is either: 1. An error. 2. The list of rows inserted, deleted, selected, etc. (2) is currently represented by a combination of the Result class and the ResultSet list it holds. This worked okay, but issues start to arise when trying to use Result in non-statement contexts (for example, when introducing Result to SQL expression execution). What we really need is for Result to be a thin wrapper that represents both (1) and (2), and to not have any explicit members like a ResultSet. So this commit removes ResultSet from Result, and introduces ResultOr, which is just an alias for AK::ErrorOrr. Statement execution now returns ResultOr<ResultSet> instead of Result. This further opens the door for expression execution to return ResultOr<Value> in the future. Lastly, this moves some other context held by Result over to ResultSet. This includes the row count (which is really just the size of ResultSet) and the command for which the result is for.
2022-02-10 14:43:00 -05:00
EXPECT_EQ(result.size(), 25u);
for (auto& row : result) {
LibSQL+SQLServer: Implement first cut of SELECT ... ORDER BY foo Ordering is done by replacing the straight Vector holding the query result in the SQLResult object with a dedicated Vector subclass that inserts result rows according to their sort key using a binary search. This is done in the ResultSet class. There are limitations: - "SELECT ... ORDER BY 1" (or 2 or 3 etc) is supposed to sort by the n-th result column. This doesn't work yet - "SELECT ... column-expression alias ... ORDER BY alias" is supposed to sort by the column with the given alias. This doesn't work yet What does work however is something like ```SELECT foo FROM bar SORT BY quux``` i.e. sorted by a column not in the result set. Once functions are supported it should be possible to sort by random functions.
2022-01-12 09:49:43 -05:00
EXPECT(row.row.size() == 4);
EXPECT(row.row[1].to_int().value() >= 42);
EXPECT(row.row[1].to_int().value() <= 46);
EXPECT(row.row[3].to_int().value() >= 40);
EXPECT(row.row[3].to_int().value() <= 48);
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
}
}
TEST_CASE(select_inner_join)
{
ScopeGuard guard([]() { unlink(db_name); });
auto database = SQL::Database::construct(db_name);
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
EXPECT(!database->open().is_error());
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
create_two_tables(database);
auto result = execute(database,
"INSERT INTO TestSchema.TestTable1 ( TextColumn1, IntColumn ) VALUES "
"( 'Test_1', 42 ), "
"( 'Test_2', 43 ), "
"( 'Test_3', 44 ), "
"( 'Test_4', 45 ), "
"( 'Test_5', 46 );");
LibSQL+SQLServer: Introduce and use ResultOr<ValueType> The result of a SQL statement execution is either: 1. An error. 2. The list of rows inserted, deleted, selected, etc. (2) is currently represented by a combination of the Result class and the ResultSet list it holds. This worked okay, but issues start to arise when trying to use Result in non-statement contexts (for example, when introducing Result to SQL expression execution). What we really need is for Result to be a thin wrapper that represents both (1) and (2), and to not have any explicit members like a ResultSet. So this commit removes ResultSet from Result, and introduces ResultOr, which is just an alias for AK::ErrorOrr. Statement execution now returns ResultOr<ResultSet> instead of Result. This further opens the door for expression execution to return ResultOr<Value> in the future. Lastly, this moves some other context held by Result over to ResultSet. This includes the row count (which is really just the size of ResultSet) and the command for which the result is for.
2022-02-10 14:43:00 -05:00
EXPECT(result.size() == 5);
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
result = execute(database,
"INSERT INTO TestSchema.TestTable2 ( TextColumn2, IntColumn ) VALUES "
"( 'Test_10', 40 ), "
"( 'Test_11', 41 ), "
"( 'Test_12', 42 ), "
"( 'Test_13', 47 ), "
"( 'Test_14', 48 );");
LibSQL+SQLServer: Introduce and use ResultOr<ValueType> The result of a SQL statement execution is either: 1. An error. 2. The list of rows inserted, deleted, selected, etc. (2) is currently represented by a combination of the Result class and the ResultSet list it holds. This worked okay, but issues start to arise when trying to use Result in non-statement contexts (for example, when introducing Result to SQL expression execution). What we really need is for Result to be a thin wrapper that represents both (1) and (2), and to not have any explicit members like a ResultSet. So this commit removes ResultSet from Result, and introduces ResultOr, which is just an alias for AK::ErrorOrr. Statement execution now returns ResultOr<ResultSet> instead of Result. This further opens the door for expression execution to return ResultOr<Value> in the future. Lastly, this moves some other context held by Result over to ResultSet. This includes the row count (which is really just the size of ResultSet) and the command for which the result is for.
2022-02-10 14:43:00 -05:00
EXPECT(result.size() == 5);
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
result = execute(database,
"SELECT TestTable1.IntColumn, TextColumn1, TextColumn2 "
"FROM TestSchema.TestTable1, TestSchema.TestTable2 "
"WHERE TestTable1.IntColumn = TestTable2.IntColumn;");
LibSQL+SQLServer: Introduce and use ResultOr<ValueType> The result of a SQL statement execution is either: 1. An error. 2. The list of rows inserted, deleted, selected, etc. (2) is currently represented by a combination of the Result class and the ResultSet list it holds. This worked okay, but issues start to arise when trying to use Result in non-statement contexts (for example, when introducing Result to SQL expression execution). What we really need is for Result to be a thin wrapper that represents both (1) and (2), and to not have any explicit members like a ResultSet. So this commit removes ResultSet from Result, and introduces ResultOr, which is just an alias for AK::ErrorOrr. Statement execution now returns ResultOr<ResultSet> instead of Result. This further opens the door for expression execution to return ResultOr<Value> in the future. Lastly, this moves some other context held by Result over to ResultSet. This includes the row count (which is really just the size of ResultSet) and the command for which the result is for.
2022-02-10 14:43:00 -05:00
EXPECT_EQ(result.size(), 1u);
EXPECT_EQ(result[0].row.size(), 3u);
EXPECT_EQ(result[0].row[0].to_int().value(), 42);
EXPECT_EQ(result[0].row[1].to_string(), "Test_1");
EXPECT_EQ(result[0].row[2].to_string(), "Test_12");
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
}
LibSQL: Implement LIKE SQL expressions
2021-12-29 11:47:29 -03:00
TEST_CASE(select_with_like)
{
ScopeGuard guard([]() { unlink(db_name); });
auto database = SQL::Database::construct(db_name);
EXPECT(!database->open().is_error());
create_table(database);
auto result = execute(database,
"INSERT INTO TestSchema.TestTable ( TextColumn, IntColumn ) VALUES "
"( 'Test+1', 42 ), "
"( 'Test+2', 43 ), "
"( 'Test+3', 44 ), "
"( 'Test+4', 45 ), "
"( 'Test+5', 46 ), "
"( 'Another+Test_6', 47 );");
LibSQL+SQLServer: Introduce and use ResultOr<ValueType> The result of a SQL statement execution is either: 1. An error. 2. The list of rows inserted, deleted, selected, etc. (2) is currently represented by a combination of the Result class and the ResultSet list it holds. This worked okay, but issues start to arise when trying to use Result in non-statement contexts (for example, when introducing Result to SQL expression execution). What we really need is for Result to be a thin wrapper that represents both (1) and (2), and to not have any explicit members like a ResultSet. So this commit removes ResultSet from Result, and introduces ResultOr, which is just an alias for AK::ErrorOrr. Statement execution now returns ResultOr<ResultSet> instead of Result. This further opens the door for expression execution to return ResultOr<Value> in the future. Lastly, this moves some other context held by Result over to ResultSet. This includes the row count (which is really just the size of ResultSet) and the command for which the result is for.
2022-02-10 14:43:00 -05:00
EXPECT(result.size() == 6);
LibSQL: Implement LIKE SQL expressions
2021-12-29 11:47:29 -03:00
// Simple match
result = execute(database, "SELECT TextColumn FROM TestSchema.TestTable WHERE TextColumn LIKE 'Test+1';");
LibSQL+SQLServer: Introduce and use ResultOr<ValueType> The result of a SQL statement execution is either: 1. An error. 2. The list of rows inserted, deleted, selected, etc. (2) is currently represented by a combination of the Result class and the ResultSet list it holds. This worked okay, but issues start to arise when trying to use Result in non-statement contexts (for example, when introducing Result to SQL expression execution). What we really need is for Result to be a thin wrapper that represents both (1) and (2), and to not have any explicit members like a ResultSet. So this commit removes ResultSet from Result, and introduces ResultOr, which is just an alias for AK::ErrorOrr. Statement execution now returns ResultOr<ResultSet> instead of Result. This further opens the door for expression execution to return ResultOr<Value> in the future. Lastly, this moves some other context held by Result over to ResultSet. This includes the row count (which is really just the size of ResultSet) and the command for which the result is for.
2022-02-10 14:43:00 -05:00
EXPECT_EQ(result.size(), 1u);
LibSQL: Implement LIKE SQL expressions
2021-12-29 11:47:29 -03:00
// Use % to match most rows
result = execute(database, "SELECT TextColumn FROM TestSchema.TestTable WHERE TextColumn LIKE 'T%';");
LibSQL+SQLServer: Introduce and use ResultOr<ValueType> The result of a SQL statement execution is either: 1. An error. 2. The list of rows inserted, deleted, selected, etc. (2) is currently represented by a combination of the Result class and the ResultSet list it holds. This worked okay, but issues start to arise when trying to use Result in non-statement contexts (for example, when introducing Result to SQL expression execution). What we really need is for Result to be a thin wrapper that represents both (1) and (2), and to not have any explicit members like a ResultSet. So this commit removes ResultSet from Result, and introduces ResultOr, which is just an alias for AK::ErrorOrr. Statement execution now returns ResultOr<ResultSet> instead of Result. This further opens the door for expression execution to return ResultOr<Value> in the future. Lastly, this moves some other context held by Result over to ResultSet. This includes the row count (which is really just the size of ResultSet) and the command for which the result is for.
2022-02-10 14:43:00 -05:00
EXPECT_EQ(result.size(), 5u);
LibSQL: Implement LIKE SQL expressions
2021-12-29 11:47:29 -03:00
// Same as above but invert the match
result = execute(database, "SELECT TextColumn FROM TestSchema.TestTable WHERE TextColumn NOT LIKE 'T%';");
LibSQL+SQLServer: Introduce and use ResultOr<ValueType> The result of a SQL statement execution is either: 1. An error. 2. The list of rows inserted, deleted, selected, etc. (2) is currently represented by a combination of the Result class and the ResultSet list it holds. This worked okay, but issues start to arise when trying to use Result in non-statement contexts (for example, when introducing Result to SQL expression execution). What we really need is for Result to be a thin wrapper that represents both (1) and (2), and to not have any explicit members like a ResultSet. So this commit removes ResultSet from Result, and introduces ResultOr, which is just an alias for AK::ErrorOrr. Statement execution now returns ResultOr<ResultSet> instead of Result. This further opens the door for expression execution to return ResultOr<Value> in the future. Lastly, this moves some other context held by Result over to ResultSet. This includes the row count (which is really just the size of ResultSet) and the command for which the result is for.
2022-02-10 14:43:00 -05:00
EXPECT_EQ(result.size(), 1u);
LibSQL: Implement LIKE SQL expressions
2021-12-29 11:47:29 -03:00
// Use _ and % to match all rows
result = execute(database, "SELECT TextColumn FROM TestSchema.TestTable WHERE TextColumn LIKE '%e_t%';");
LibSQL+SQLServer: Introduce and use ResultOr<ValueType> The result of a SQL statement execution is either: 1. An error. 2. The list of rows inserted, deleted, selected, etc. (2) is currently represented by a combination of the Result class and the ResultSet list it holds. This worked okay, but issues start to arise when trying to use Result in non-statement contexts (for example, when introducing Result to SQL expression execution). What we really need is for Result to be a thin wrapper that represents both (1) and (2), and to not have any explicit members like a ResultSet. So this commit removes ResultSet from Result, and introduces ResultOr, which is just an alias for AK::ErrorOrr. Statement execution now returns ResultOr<ResultSet> instead of Result. This further opens the door for expression execution to return ResultOr<Value> in the future. Lastly, this moves some other context held by Result over to ResultSet. This includes the row count (which is really just the size of ResultSet) and the command for which the result is for.
2022-02-10 14:43:00 -05:00
EXPECT_EQ(result.size(), 6u);
LibSQL: Implement LIKE SQL expressions
2021-12-29 11:47:29 -03:00
// Use escape to match a single row. The escape character happens to be a
// Regex metacharacter, let's make sure we don't get confused by that.
result = execute(database, "SELECT TextColumn FROM TestSchema.TestTable WHERE TextColumn LIKE '%Test^_%' ESCAPE '^';");
LibSQL+SQLServer: Introduce and use ResultOr<ValueType> The result of a SQL statement execution is either: 1. An error. 2. The list of rows inserted, deleted, selected, etc. (2) is currently represented by a combination of the Result class and the ResultSet list it holds. This worked okay, but issues start to arise when trying to use Result in non-statement contexts (for example, when introducing Result to SQL expression execution). What we really need is for Result to be a thin wrapper that represents both (1) and (2), and to not have any explicit members like a ResultSet. So this commit removes ResultSet from Result, and introduces ResultOr, which is just an alias for AK::ErrorOrr. Statement execution now returns ResultOr<ResultSet> instead of Result. This further opens the door for expression execution to return ResultOr<Value> in the future. Lastly, this moves some other context held by Result over to ResultSet. This includes the row count (which is really just the size of ResultSet) and the command for which the result is for.
2022-02-10 14:43:00 -05:00
EXPECT_EQ(result.size(), 1u);
LibSQL: Implement LIKE SQL expressions
2021-12-29 11:47:29 -03:00
// Same as above but escape the escape character happens to be a SQL
// metacharacter - we want to make sure it's treated as an escape.
result = execute(database, "SELECT TextColumn FROM TestSchema.TestTable WHERE TextColumn LIKE '%Test__%' ESCAPE '_';");
LibSQL+SQLServer: Introduce and use ResultOr<ValueType> The result of a SQL statement execution is either: 1. An error. 2. The list of rows inserted, deleted, selected, etc. (2) is currently represented by a combination of the Result class and the ResultSet list it holds. This worked okay, but issues start to arise when trying to use Result in non-statement contexts (for example, when introducing Result to SQL expression execution). What we really need is for Result to be a thin wrapper that represents both (1) and (2), and to not have any explicit members like a ResultSet. So this commit removes ResultSet from Result, and introduces ResultOr, which is just an alias for AK::ErrorOrr. Statement execution now returns ResultOr<ResultSet> instead of Result. This further opens the door for expression execution to return ResultOr<Value> in the future. Lastly, this moves some other context held by Result over to ResultSet. This includes the row count (which is really just the size of ResultSet) and the command for which the result is for.
2022-02-10 14:43:00 -05:00
EXPECT_EQ(result.size(), 1u);
LibSQL: Implement LIKE SQL expressions
2021-12-29 11:47:29 -03:00
// (Unnecessarily) escaping a character that happens to be a Regex
// metacharacter should have no effect.
result = execute(database, "SELECT TextColumn FROM TestSchema.TestTable WHERE TextColumn LIKE 'Test:+_' ESCAPE ':';");
LibSQL+SQLServer: Introduce and use ResultOr<ValueType> The result of a SQL statement execution is either: 1. An error. 2. The list of rows inserted, deleted, selected, etc. (2) is currently represented by a combination of the Result class and the ResultSet list it holds. This worked okay, but issues start to arise when trying to use Result in non-statement contexts (for example, when introducing Result to SQL expression execution). What we really need is for Result to be a thin wrapper that represents both (1) and (2), and to not have any explicit members like a ResultSet. So this commit removes ResultSet from Result, and introduces ResultOr, which is just an alias for AK::ErrorOrr. Statement execution now returns ResultOr<ResultSet> instead of Result. This further opens the door for expression execution to return ResultOr<Value> in the future. Lastly, this moves some other context held by Result over to ResultSet. This includes the row count (which is really just the size of ResultSet) and the command for which the result is for.
2022-02-10 14:43:00 -05:00
EXPECT_EQ(result.size(), 5u);
LibSQL: Implement LIKE SQL expressions
2021-12-29 11:47:29 -03:00
// Make sure we error out if the ESCAPE is empty
LibSQL+SQLServer: Introduce and use ResultOr<ValueType> The result of a SQL statement execution is either: 1. An error. 2. The list of rows inserted, deleted, selected, etc. (2) is currently represented by a combination of the Result class and the ResultSet list it holds. This worked okay, but issues start to arise when trying to use Result in non-statement contexts (for example, when introducing Result to SQL expression execution). What we really need is for Result to be a thin wrapper that represents both (1) and (2), and to not have any explicit members like a ResultSet. So this commit removes ResultSet from Result, and introduces ResultOr, which is just an alias for AK::ErrorOrr. Statement execution now returns ResultOr<ResultSet> instead of Result. This further opens the door for expression execution to return ResultOr<Value> in the future. Lastly, this moves some other context held by Result over to ResultSet. This includes the row count (which is really just the size of ResultSet) and the command for which the result is for.
2022-02-10 14:43:00 -05:00
auto select_result = try_execute(database, "SELECT TextColumn FROM TestSchema.TestTable WHERE TextColumn LIKE '%' ESCAPE '';");
EXPECT(select_result.is_error());
EXPECT(select_result.release_error().error() == SQL::SQLErrorCode::SyntaxError);
LibSQL: Implement LIKE SQL expressions
2021-12-29 11:47:29 -03:00
// Make sure we error out if the ESCAPE has more than a single character
LibSQL+SQLServer: Introduce and use ResultOr<ValueType> The result of a SQL statement execution is either: 1. An error. 2. The list of rows inserted, deleted, selected, etc. (2) is currently represented by a combination of the Result class and the ResultSet list it holds. This worked okay, but issues start to arise when trying to use Result in non-statement contexts (for example, when introducing Result to SQL expression execution). What we really need is for Result to be a thin wrapper that represents both (1) and (2), and to not have any explicit members like a ResultSet. So this commit removes ResultSet from Result, and introduces ResultOr, which is just an alias for AK::ErrorOrr. Statement execution now returns ResultOr<ResultSet> instead of Result. This further opens the door for expression execution to return ResultOr<Value> in the future. Lastly, this moves some other context held by Result over to ResultSet. This includes the row count (which is really just the size of ResultSet) and the command for which the result is for.
2022-02-10 14:43:00 -05:00
select_result = try_execute(database, "SELECT TextColumn FROM TestSchema.TestTable WHERE TextColumn LIKE '%' ESCAPE 'whf';");
EXPECT(select_result.is_error());
EXPECT(select_result.release_error().error() == SQL::SQLErrorCode::SyntaxError);
LibSQL: Implement LIKE SQL expressions
2021-12-29 11:47:29 -03:00
}
LibSQL+SQLServer: Implement first cut of SELECT ... ORDER BY foo Ordering is done by replacing the straight Vector holding the query result in the SQLResult object with a dedicated Vector subclass that inserts result rows according to their sort key using a binary search. This is done in the ResultSet class. There are limitations: - "SELECT ... ORDER BY 1" (or 2 or 3 etc) is supposed to sort by the n-th result column. This doesn't work yet - "SELECT ... column-expression alias ... ORDER BY alias" is supposed to sort by the column with the given alias. This doesn't work yet What does work however is something like ```SELECT foo FROM bar SORT BY quux``` i.e. sorted by a column not in the result set. Once functions are supported it should be possible to sort by random functions.
2022-01-12 09:49:43 -05:00
TEST_CASE(select_with_order)
{
ScopeGuard guard([]() { unlink(db_name); });
auto database = SQL::Database::construct(db_name);
EXPECT(!database->open().is_error());
create_table(database);
auto result = execute(database,
"INSERT INTO TestSchema.TestTable ( TextColumn, IntColumn ) VALUES "
"( 'Test_5', 44 ), "
"( 'Test_2', 42 ), "
"( 'Test_1', 47 ), "
"( 'Test_3', 40 ), "
"( 'Test_4', 41 );");
LibSQL+SQLServer: Introduce and use ResultOr<ValueType> The result of a SQL statement execution is either: 1. An error. 2. The list of rows inserted, deleted, selected, etc. (2) is currently represented by a combination of the Result class and the ResultSet list it holds. This worked okay, but issues start to arise when trying to use Result in non-statement contexts (for example, when introducing Result to SQL expression execution). What we really need is for Result to be a thin wrapper that represents both (1) and (2), and to not have any explicit members like a ResultSet. So this commit removes ResultSet from Result, and introduces ResultOr, which is just an alias for AK::ErrorOrr. Statement execution now returns ResultOr<ResultSet> instead of Result. This further opens the door for expression execution to return ResultOr<Value> in the future. Lastly, this moves some other context held by Result over to ResultSet. This includes the row count (which is really just the size of ResultSet) and the command for which the result is for.
2022-02-10 14:43:00 -05:00
EXPECT(result.size() == 5);
LibSQL+SQLServer: Implement first cut of SELECT ... ORDER BY foo Ordering is done by replacing the straight Vector holding the query result in the SQLResult object with a dedicated Vector subclass that inserts result rows according to their sort key using a binary search. This is done in the ResultSet class. There are limitations: - "SELECT ... ORDER BY 1" (or 2 or 3 etc) is supposed to sort by the n-th result column. This doesn't work yet - "SELECT ... column-expression alias ... ORDER BY alias" is supposed to sort by the column with the given alias. This doesn't work yet What does work however is something like ```SELECT foo FROM bar SORT BY quux``` i.e. sorted by a column not in the result set. Once functions are supported it should be possible to sort by random functions.
2022-01-12 09:49:43 -05:00
result = execute(database, "SELECT TextColumn, IntColumn FROM TestSchema.TestTable ORDER BY IntColumn;");
LibSQL+SQLServer: Introduce and use ResultOr<ValueType> The result of a SQL statement execution is either: 1. An error. 2. The list of rows inserted, deleted, selected, etc. (2) is currently represented by a combination of the Result class and the ResultSet list it holds. This worked okay, but issues start to arise when trying to use Result in non-statement contexts (for example, when introducing Result to SQL expression execution). What we really need is for Result to be a thin wrapper that represents both (1) and (2), and to not have any explicit members like a ResultSet. So this commit removes ResultSet from Result, and introduces ResultOr, which is just an alias for AK::ErrorOrr. Statement execution now returns ResultOr<ResultSet> instead of Result. This further opens the door for expression execution to return ResultOr<Value> in the future. Lastly, this moves some other context held by Result over to ResultSet. This includes the row count (which is really just the size of ResultSet) and the command for which the result is for.
2022-02-10 14:43:00 -05:00
EXPECT_EQ(result.size(), 5u);
EXPECT_EQ(result[0].row[1].to_int().value(), 40);
EXPECT_EQ(result[1].row[1].to_int().value(), 41);
EXPECT_EQ(result[2].row[1].to_int().value(), 42);
EXPECT_EQ(result[3].row[1].to_int().value(), 44);
EXPECT_EQ(result[4].row[1].to_int().value(), 47);
LibSQL+SQLServer: Implement first cut of SELECT ... ORDER BY foo Ordering is done by replacing the straight Vector holding the query result in the SQLResult object with a dedicated Vector subclass that inserts result rows according to their sort key using a binary search. This is done in the ResultSet class. There are limitations: - "SELECT ... ORDER BY 1" (or 2 or 3 etc) is supposed to sort by the n-th result column. This doesn't work yet - "SELECT ... column-expression alias ... ORDER BY alias" is supposed to sort by the column with the given alias. This doesn't work yet What does work however is something like ```SELECT foo FROM bar SORT BY quux``` i.e. sorted by a column not in the result set. Once functions are supported it should be possible to sort by random functions.
2022-01-12 09:49:43 -05:00
result = execute(database, "SELECT TextColumn, IntColumn FROM TestSchema.TestTable ORDER BY TextColumn;");
LibSQL+SQLServer: Introduce and use ResultOr<ValueType> The result of a SQL statement execution is either: 1. An error. 2. The list of rows inserted, deleted, selected, etc. (2) is currently represented by a combination of the Result class and the ResultSet list it holds. This worked okay, but issues start to arise when trying to use Result in non-statement contexts (for example, when introducing Result to SQL expression execution). What we really need is for Result to be a thin wrapper that represents both (1) and (2), and to not have any explicit members like a ResultSet. So this commit removes ResultSet from Result, and introduces ResultOr, which is just an alias for AK::ErrorOrr. Statement execution now returns ResultOr<ResultSet> instead of Result. This further opens the door for expression execution to return ResultOr<Value> in the future. Lastly, this moves some other context held by Result over to ResultSet. This includes the row count (which is really just the size of ResultSet) and the command for which the result is for.
2022-02-10 14:43:00 -05:00
EXPECT_EQ(result.size(), 5u);
EXPECT_EQ(result[0].row[0].to_string(), "Test_1");
EXPECT_EQ(result[1].row[0].to_string(), "Test_2");
EXPECT_EQ(result[2].row[0].to_string(), "Test_3");
EXPECT_EQ(result[3].row[0].to_string(), "Test_4");
EXPECT_EQ(result[4].row[0].to_string(), "Test_5");
LibSQL+SQLServer: Implement first cut of SELECT ... ORDER BY foo Ordering is done by replacing the straight Vector holding the query result in the SQLResult object with a dedicated Vector subclass that inserts result rows according to their sort key using a binary search. This is done in the ResultSet class. There are limitations: - "SELECT ... ORDER BY 1" (or 2 or 3 etc) is supposed to sort by the n-th result column. This doesn't work yet - "SELECT ... column-expression alias ... ORDER BY alias" is supposed to sort by the column with the given alias. This doesn't work yet What does work however is something like ```SELECT foo FROM bar SORT BY quux``` i.e. sorted by a column not in the result set. Once functions are supported it should be possible to sort by random functions.
2022-01-12 09:49:43 -05:00
}
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
TEST_CASE(select_with_regexp)
{
ScopeGuard guard([]() { unlink(db_name); });
auto database = SQL::Database::construct(db_name);
EXPECT(!database->open().is_error());
create_table(database);
auto result = execute(database,
"INSERT INTO TestSchema.TestTable ( TextColumn, IntColumn ) VALUES "
"( 'Test+1', 42 ), "
"( 'Pröv+2', 43 ), "
"( 'Test(3)', 44 ), "
"( 'Test[4]', 45 ), "
"( 'Test+5', 46 ), "
"( 'Another-Test_6', 47 );");
LibSQL+SQLServer: Introduce and use ResultOr<ValueType> The result of a SQL statement execution is either: 1. An error. 2. The list of rows inserted, deleted, selected, etc. (2) is currently represented by a combination of the Result class and the ResultSet list it holds. This worked okay, but issues start to arise when trying to use Result in non-statement contexts (for example, when introducing Result to SQL expression execution). What we really need is for Result to be a thin wrapper that represents both (1) and (2), and to not have any explicit members like a ResultSet. So this commit removes ResultSet from Result, and introduces ResultOr, which is just an alias for AK::ErrorOrr. Statement execution now returns ResultOr<ResultSet> instead of Result. This further opens the door for expression execution to return ResultOr<Value> in the future. Lastly, this moves some other context held by Result over to ResultSet. This includes the row count (which is really just the size of ResultSet) and the command for which the result is for.
2022-02-10 14:43:00 -05:00
EXPECT(result.size() == 6);
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
// Simple match
result = execute(database, "SELECT TextColumn FROM TestSchema.TestTable WHERE TextColumn REGEXP 'Test\\+1';");
LibSQL+SQLServer: Introduce and use ResultOr<ValueType> The result of a SQL statement execution is either: 1. An error. 2. The list of rows inserted, deleted, selected, etc. (2) is currently represented by a combination of the Result class and the ResultSet list it holds. This worked okay, but issues start to arise when trying to use Result in non-statement contexts (for example, when introducing Result to SQL expression execution). What we really need is for Result to be a thin wrapper that represents both (1) and (2), and to not have any explicit members like a ResultSet. So this commit removes ResultSet from Result, and introduces ResultOr, which is just an alias for AK::ErrorOrr. Statement execution now returns ResultOr<ResultSet> instead of Result. This further opens the door for expression execution to return ResultOr<Value> in the future. Lastly, this moves some other context held by Result over to ResultSet. This includes the row count (which is really just the size of ResultSet) and the command for which the result is for.
2022-02-10 14:43:00 -05:00
EXPECT_EQ(result.size(), 1u);
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
// Match all
result = execute(database, "SELECT TextColumn FROM TestSchema.TestTable WHERE TextColumn REGEXP '.*';");
LibSQL+SQLServer: Introduce and use ResultOr<ValueType> The result of a SQL statement execution is either: 1. An error. 2. The list of rows inserted, deleted, selected, etc. (2) is currently represented by a combination of the Result class and the ResultSet list it holds. This worked okay, but issues start to arise when trying to use Result in non-statement contexts (for example, when introducing Result to SQL expression execution). What we really need is for Result to be a thin wrapper that represents both (1) and (2), and to not have any explicit members like a ResultSet. So this commit removes ResultSet from Result, and introduces ResultOr, which is just an alias for AK::ErrorOrr. Statement execution now returns ResultOr<ResultSet> instead of Result. This further opens the door for expression execution to return ResultOr<Value> in the future. Lastly, this moves some other context held by Result over to ResultSet. This includes the row count (which is really just the size of ResultSet) and the command for which the result is for.
2022-02-10 14:43:00 -05:00
EXPECT_EQ(result.size(), 6u);
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
// Match with wildcards
result = execute(database, "SELECT TextColumn FROM TestSchema.TestTable WHERE TextColumn REGEXP '^Test.+';");
LibSQL+SQLServer: Introduce and use ResultOr<ValueType> The result of a SQL statement execution is either: 1. An error. 2. The list of rows inserted, deleted, selected, etc. (2) is currently represented by a combination of the Result class and the ResultSet list it holds. This worked okay, but issues start to arise when trying to use Result in non-statement contexts (for example, when introducing Result to SQL expression execution). What we really need is for Result to be a thin wrapper that represents both (1) and (2), and to not have any explicit members like a ResultSet. So this commit removes ResultSet from Result, and introduces ResultOr, which is just an alias for AK::ErrorOrr. Statement execution now returns ResultOr<ResultSet> instead of Result. This further opens the door for expression execution to return ResultOr<Value> in the future. Lastly, this moves some other context held by Result over to ResultSet. This includes the row count (which is really just the size of ResultSet) and the command for which the result is for.
2022-02-10 14:43:00 -05:00
EXPECT_EQ(result.size(), 4u);
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
// Match with case insensitive basic Latin and case sensitive Swedish ö
// FIXME: If LibRegex is changed to support case insensitive matches of Unicode characters
// This test should be updated and changed to match 'PRÖV'.
result = execute(database, "SELECT TextColumn FROM TestSchema.TestTable WHERE TextColumn REGEXP 'PRöV.*';");
LibSQL+SQLServer: Introduce and use ResultOr<ValueType> The result of a SQL statement execution is either: 1. An error. 2. The list of rows inserted, deleted, selected, etc. (2) is currently represented by a combination of the Result class and the ResultSet list it holds. This worked okay, but issues start to arise when trying to use Result in non-statement contexts (for example, when introducing Result to SQL expression execution). What we really need is for Result to be a thin wrapper that represents both (1) and (2), and to not have any explicit members like a ResultSet. So this commit removes ResultSet from Result, and introduces ResultOr, which is just an alias for AK::ErrorOrr. Statement execution now returns ResultOr<ResultSet> instead of Result. This further opens the door for expression execution to return ResultOr<Value> in the future. Lastly, this moves some other context held by Result over to ResultSet. This includes the row count (which is really just the size of ResultSet) and the command for which the result is for.
2022-02-10 14:43:00 -05:00
EXPECT_EQ(result.size(), 1u);
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
}
TEST_CASE(handle_regexp_errors)
{
ScopeGuard guard([]() { unlink(db_name); });
auto database = SQL::Database::construct(db_name);
EXPECT(!database->open().is_error());
create_table(database);
auto result = execute(database,
"INSERT INTO TestSchema.TestTable ( TextColumn, IntColumn ) VALUES "
"( 'Test', 0 );");
LibSQL+SQLServer: Introduce and use ResultOr<ValueType> The result of a SQL statement execution is either: 1. An error. 2. The list of rows inserted, deleted, selected, etc. (2) is currently represented by a combination of the Result class and the ResultSet list it holds. This worked okay, but issues start to arise when trying to use Result in non-statement contexts (for example, when introducing Result to SQL expression execution). What we really need is for Result to be a thin wrapper that represents both (1) and (2), and to not have any explicit members like a ResultSet. So this commit removes ResultSet from Result, and introduces ResultOr, which is just an alias for AK::ErrorOrr. Statement execution now returns ResultOr<ResultSet> instead of Result. This further opens the door for expression execution to return ResultOr<Value> in the future. Lastly, this moves some other context held by Result over to ResultSet. This includes the row count (which is really just the size of ResultSet) and the command for which the result is for.
2022-02-10 14:43:00 -05:00
EXPECT(result.size() == 1);
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
// Malformed regex, unmatched square bracket
LibSQL+SQLServer: Introduce and use ResultOr<ValueType> The result of a SQL statement execution is either: 1. An error. 2. The list of rows inserted, deleted, selected, etc. (2) is currently represented by a combination of the Result class and the ResultSet list it holds. This worked okay, but issues start to arise when trying to use Result in non-statement contexts (for example, when introducing Result to SQL expression execution). What we really need is for Result to be a thin wrapper that represents both (1) and (2), and to not have any explicit members like a ResultSet. So this commit removes ResultSet from Result, and introduces ResultOr, which is just an alias for AK::ErrorOrr. Statement execution now returns ResultOr<ResultSet> instead of Result. This further opens the door for expression execution to return ResultOr<Value> in the future. Lastly, this moves some other context held by Result over to ResultSet. This includes the row count (which is really just the size of ResultSet) and the command for which the result is for.
2022-02-10 14:43:00 -05:00
auto select_result = try_execute(database, "SELECT TextColumn FROM TestSchema.TestTable WHERE TextColumn REGEXP 'Test\\+[0-9.*';");
EXPECT(select_result.is_error());
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
}
LibSQL+SQLServer: Implement first cut of SELECT ... ORDER BY foo Ordering is done by replacing the straight Vector holding the query result in the SQLResult object with a dedicated Vector subclass that inserts result rows according to their sort key using a binary search. This is done in the ResultSet class. There are limitations: - "SELECT ... ORDER BY 1" (or 2 or 3 etc) is supposed to sort by the n-th result column. This doesn't work yet - "SELECT ... column-expression alias ... ORDER BY alias" is supposed to sort by the column with the given alias. This doesn't work yet What does work however is something like ```SELECT foo FROM bar SORT BY quux``` i.e. sorted by a column not in the result set. Once functions are supported it should be possible to sort by random functions.
2022-01-12 09:49:43 -05:00
TEST_CASE(select_with_order_two_columns)
{
ScopeGuard guard([]() { unlink(db_name); });
auto database = SQL::Database::construct(db_name);
EXPECT(!database->open().is_error());
create_table(database);
auto result = execute(database,
"INSERT INTO TestSchema.TestTable ( TextColumn, IntColumn ) VALUES "
"( 'Test_5', 44 ), "
"( 'Test_2', 42 ), "
"( 'Test_1', 47 ), "
"( 'Test_2', 40 ), "
"( 'Test_4', 41 );");
LibSQL+SQLServer: Introduce and use ResultOr<ValueType> The result of a SQL statement execution is either: 1. An error. 2. The list of rows inserted, deleted, selected, etc. (2) is currently represented by a combination of the Result class and the ResultSet list it holds. This worked okay, but issues start to arise when trying to use Result in non-statement contexts (for example, when introducing Result to SQL expression execution). What we really need is for Result to be a thin wrapper that represents both (1) and (2), and to not have any explicit members like a ResultSet. So this commit removes ResultSet from Result, and introduces ResultOr, which is just an alias for AK::ErrorOrr. Statement execution now returns ResultOr<ResultSet> instead of Result. This further opens the door for expression execution to return ResultOr<Value> in the future. Lastly, this moves some other context held by Result over to ResultSet. This includes the row count (which is really just the size of ResultSet) and the command for which the result is for.
2022-02-10 14:43:00 -05:00
EXPECT(result.size() == 5);
LibSQL+SQLServer: Implement first cut of SELECT ... ORDER BY foo Ordering is done by replacing the straight Vector holding the query result in the SQLResult object with a dedicated Vector subclass that inserts result rows according to their sort key using a binary search. This is done in the ResultSet class. There are limitations: - "SELECT ... ORDER BY 1" (or 2 or 3 etc) is supposed to sort by the n-th result column. This doesn't work yet - "SELECT ... column-expression alias ... ORDER BY alias" is supposed to sort by the column with the given alias. This doesn't work yet What does work however is something like ```SELECT foo FROM bar SORT BY quux``` i.e. sorted by a column not in the result set. Once functions are supported it should be possible to sort by random functions.
2022-01-12 09:49:43 -05:00
result = execute(database, "SELECT TextColumn, IntColumn FROM TestSchema.TestTable ORDER BY TextColumn, IntColumn;");
LibSQL+SQLServer: Introduce and use ResultOr<ValueType> The result of a SQL statement execution is either: 1. An error. 2. The list of rows inserted, deleted, selected, etc. (2) is currently represented by a combination of the Result class and the ResultSet list it holds. This worked okay, but issues start to arise when trying to use Result in non-statement contexts (for example, when introducing Result to SQL expression execution). What we really need is for Result to be a thin wrapper that represents both (1) and (2), and to not have any explicit members like a ResultSet. So this commit removes ResultSet from Result, and introduces ResultOr, which is just an alias for AK::ErrorOrr. Statement execution now returns ResultOr<ResultSet> instead of Result. This further opens the door for expression execution to return ResultOr<Value> in the future. Lastly, this moves some other context held by Result over to ResultSet. This includes the row count (which is really just the size of ResultSet) and the command for which the result is for.
2022-02-10 14:43:00 -05:00
EXPECT_EQ(result.size(), 5u);
EXPECT_EQ(result[0].row[0].to_string(), "Test_1");
EXPECT_EQ(result[0].row[1].to_int().value(), 47);
EXPECT_EQ(result[1].row[0].to_string(), "Test_2");
EXPECT_EQ(result[1].row[1].to_int().value(), 40);
EXPECT_EQ(result[2].row[0].to_string(), "Test_2");
EXPECT_EQ(result[2].row[1].to_int().value(), 42);
EXPECT_EQ(result[3].row[0].to_string(), "Test_4");
EXPECT_EQ(result[3].row[1].to_int().value(), 41);
EXPECT_EQ(result[4].row[0].to_string(), "Test_5");
EXPECT_EQ(result[4].row[1].to_int().value(), 44);
LibSQL+SQLServer: Implement first cut of SELECT ... ORDER BY foo Ordering is done by replacing the straight Vector holding the query result in the SQLResult object with a dedicated Vector subclass that inserts result rows according to their sort key using a binary search. This is done in the ResultSet class. There are limitations: - "SELECT ... ORDER BY 1" (or 2 or 3 etc) is supposed to sort by the n-th result column. This doesn't work yet - "SELECT ... column-expression alias ... ORDER BY alias" is supposed to sort by the column with the given alias. This doesn't work yet What does work however is something like ```SELECT foo FROM bar SORT BY quux``` i.e. sorted by a column not in the result set. Once functions are supported it should be possible to sort by random functions.
2022-01-12 09:49:43 -05:00
}
TEST_CASE(select_with_order_by_column_not_in_result)
{
ScopeGuard guard([]() { unlink(db_name); });
auto database = SQL::Database::construct(db_name);
EXPECT(!database->open().is_error());
create_table(database);
auto result = execute(database,
"INSERT INTO TestSchema.TestTable ( TextColumn, IntColumn ) VALUES "
"( 'Test_5', 44 ), "
"( 'Test_2', 42 ), "
"( 'Test_1', 47 ), "
"( 'Test_3', 40 ), "
"( 'Test_4', 41 );");
LibSQL+SQLServer: Introduce and use ResultOr<ValueType> The result of a SQL statement execution is either: 1. An error. 2. The list of rows inserted, deleted, selected, etc. (2) is currently represented by a combination of the Result class and the ResultSet list it holds. This worked okay, but issues start to arise when trying to use Result in non-statement contexts (for example, when introducing Result to SQL expression execution). What we really need is for Result to be a thin wrapper that represents both (1) and (2), and to not have any explicit members like a ResultSet. So this commit removes ResultSet from Result, and introduces ResultOr, which is just an alias for AK::ErrorOrr. Statement execution now returns ResultOr<ResultSet> instead of Result. This further opens the door for expression execution to return ResultOr<Value> in the future. Lastly, this moves some other context held by Result over to ResultSet. This includes the row count (which is really just the size of ResultSet) and the command for which the result is for.
2022-02-10 14:43:00 -05:00
EXPECT(result.size() == 5);
LibSQL+SQLServer: Implement first cut of SELECT ... ORDER BY foo Ordering is done by replacing the straight Vector holding the query result in the SQLResult object with a dedicated Vector subclass that inserts result rows according to their sort key using a binary search. This is done in the ResultSet class. There are limitations: - "SELECT ... ORDER BY 1" (or 2 or 3 etc) is supposed to sort by the n-th result column. This doesn't work yet - "SELECT ... column-expression alias ... ORDER BY alias" is supposed to sort by the column with the given alias. This doesn't work yet What does work however is something like ```SELECT foo FROM bar SORT BY quux``` i.e. sorted by a column not in the result set. Once functions are supported it should be possible to sort by random functions.
2022-01-12 09:49:43 -05:00
result = execute(database, "SELECT TextColumn FROM TestSchema.TestTable ORDER BY IntColumn;");
LibSQL+SQLServer: Introduce and use ResultOr<ValueType> The result of a SQL statement execution is either: 1. An error. 2. The list of rows inserted, deleted, selected, etc. (2) is currently represented by a combination of the Result class and the ResultSet list it holds. This worked okay, but issues start to arise when trying to use Result in non-statement contexts (for example, when introducing Result to SQL expression execution). What we really need is for Result to be a thin wrapper that represents both (1) and (2), and to not have any explicit members like a ResultSet. So this commit removes ResultSet from Result, and introduces ResultOr, which is just an alias for AK::ErrorOrr. Statement execution now returns ResultOr<ResultSet> instead of Result. This further opens the door for expression execution to return ResultOr<Value> in the future. Lastly, this moves some other context held by Result over to ResultSet. This includes the row count (which is really just the size of ResultSet) and the command for which the result is for.
2022-02-10 14:43:00 -05:00
EXPECT_EQ(result.size(), 5u);
EXPECT_EQ(result[0].row[0].to_string(), "Test_3");
EXPECT_EQ(result[1].row[0].to_string(), "Test_4");
EXPECT_EQ(result[2].row[0].to_string(), "Test_2");
EXPECT_EQ(result[3].row[0].to_string(), "Test_5");
EXPECT_EQ(result[4].row[0].to_string(), "Test_1");
LibSQL+SQLServer: Implement first cut of SELECT ... ORDER BY foo Ordering is done by replacing the straight Vector holding the query result in the SQLResult object with a dedicated Vector subclass that inserts result rows according to their sort key using a binary search. This is done in the ResultSet class. There are limitations: - "SELECT ... ORDER BY 1" (or 2 or 3 etc) is supposed to sort by the n-th result column. This doesn't work yet - "SELECT ... column-expression alias ... ORDER BY alias" is supposed to sort by the column with the given alias. This doesn't work yet What does work however is something like ```SELECT foo FROM bar SORT BY quux``` i.e. sorted by a column not in the result set. Once functions are supported it should be possible to sort by random functions.
2022-01-12 09:49:43 -05:00
}
LibSQL: Introduce SELECT ... LIMIT xxx OFFSET yyy What it says on the tin.
2022-01-12 11:41:58 -05:00
TEST_CASE(select_with_limit)
{
ScopeGuard guard([]() { unlink(db_name); });
auto database = SQL::Database::construct(db_name);
EXPECT(!database->open().is_error());
create_table(database);
for (auto count = 0; count < 100; count++) {
auto result = execute(database,
String::formatted("INSERT INTO TestSchema.TestTable ( TextColumn, IntColumn ) VALUES ( 'Test_{}', {} );", count, count));
LibSQL+SQLServer: Introduce and use ResultOr<ValueType> The result of a SQL statement execution is either: 1. An error. 2. The list of rows inserted, deleted, selected, etc. (2) is currently represented by a combination of the Result class and the ResultSet list it holds. This worked okay, but issues start to arise when trying to use Result in non-statement contexts (for example, when introducing Result to SQL expression execution). What we really need is for Result to be a thin wrapper that represents both (1) and (2), and to not have any explicit members like a ResultSet. So this commit removes ResultSet from Result, and introduces ResultOr, which is just an alias for AK::ErrorOrr. Statement execution now returns ResultOr<ResultSet> instead of Result. This further opens the door for expression execution to return ResultOr<Value> in the future. Lastly, this moves some other context held by Result over to ResultSet. This includes the row count (which is really just the size of ResultSet) and the command for which the result is for.
2022-02-10 14:43:00 -05:00
EXPECT(result.size() == 1);
LibSQL: Introduce SELECT ... LIMIT xxx OFFSET yyy What it says on the tin.
2022-01-12 11:41:58 -05:00
}
auto result = execute(database, "SELECT TextColumn, IntColumn FROM TestSchema.TestTable LIMIT 10;");
LibSQL+SQLServer: Introduce and use ResultOr<ValueType> The result of a SQL statement execution is either: 1. An error. 2. The list of rows inserted, deleted, selected, etc. (2) is currently represented by a combination of the Result class and the ResultSet list it holds. This worked okay, but issues start to arise when trying to use Result in non-statement contexts (for example, when introducing Result to SQL expression execution). What we really need is for Result to be a thin wrapper that represents both (1) and (2), and to not have any explicit members like a ResultSet. So this commit removes ResultSet from Result, and introduces ResultOr, which is just an alias for AK::ErrorOrr. Statement execution now returns ResultOr<ResultSet> instead of Result. This further opens the door for expression execution to return ResultOr<Value> in the future. Lastly, this moves some other context held by Result over to ResultSet. This includes the row count (which is really just the size of ResultSet) and the command for which the result is for.
2022-02-10 14:43:00 -05:00
auto rows = result;
LibSQL: Introduce SELECT ... LIMIT xxx OFFSET yyy What it says on the tin.
2022-01-12 11:41:58 -05:00
EXPECT_EQ(rows.size(), 10u);
}
TEST_CASE(select_with_limit_and_offset)
{
ScopeGuard guard([]() { unlink(db_name); });
auto database = SQL::Database::construct(db_name);
EXPECT(!database->open().is_error());
create_table(database);
for (auto count = 0; count < 100; count++) {
auto result = execute(database,
String::formatted("INSERT INTO TestSchema.TestTable ( TextColumn, IntColumn ) VALUES ( 'Test_{}', {} );", count, count));
LibSQL+SQLServer: Introduce and use ResultOr<ValueType> The result of a SQL statement execution is either: 1. An error. 2. The list of rows inserted, deleted, selected, etc. (2) is currently represented by a combination of the Result class and the ResultSet list it holds. This worked okay, but issues start to arise when trying to use Result in non-statement contexts (for example, when introducing Result to SQL expression execution). What we really need is for Result to be a thin wrapper that represents both (1) and (2), and to not have any explicit members like a ResultSet. So this commit removes ResultSet from Result, and introduces ResultOr, which is just an alias for AK::ErrorOrr. Statement execution now returns ResultOr<ResultSet> instead of Result. This further opens the door for expression execution to return ResultOr<Value> in the future. Lastly, this moves some other context held by Result over to ResultSet. This includes the row count (which is really just the size of ResultSet) and the command for which the result is for.
2022-02-10 14:43:00 -05:00
EXPECT(result.size() == 1);
LibSQL: Introduce SELECT ... LIMIT xxx OFFSET yyy What it says on the tin.
2022-01-12 11:41:58 -05:00
}
auto result = execute(database, "SELECT TextColumn, IntColumn FROM TestSchema.TestTable LIMIT 10 OFFSET 10;");
LibSQL+SQLServer: Introduce and use ResultOr<ValueType> The result of a SQL statement execution is either: 1. An error. 2. The list of rows inserted, deleted, selected, etc. (2) is currently represented by a combination of the Result class and the ResultSet list it holds. This worked okay, but issues start to arise when trying to use Result in non-statement contexts (for example, when introducing Result to SQL expression execution). What we really need is for Result to be a thin wrapper that represents both (1) and (2), and to not have any explicit members like a ResultSet. So this commit removes ResultSet from Result, and introduces ResultOr, which is just an alias for AK::ErrorOrr. Statement execution now returns ResultOr<ResultSet> instead of Result. This further opens the door for expression execution to return ResultOr<Value> in the future. Lastly, this moves some other context held by Result over to ResultSet. This includes the row count (which is really just the size of ResultSet) and the command for which the result is for.
2022-02-10 14:43:00 -05:00
EXPECT_EQ(result.size(), 10u);
LibSQL: Introduce SELECT ... LIMIT xxx OFFSET yyy What it says on the tin.
2022-01-12 11:41:58 -05:00
}
TEST_CASE(select_with_order_limit_and_offset)
{
ScopeGuard guard([]() { unlink(db_name); });
auto database = SQL::Database::construct(db_name);
EXPECT(!database->open().is_error());
create_table(database);
for (auto count = 0; count < 100; count++) {
auto result = execute(database,
String::formatted("INSERT INTO TestSchema.TestTable ( TextColumn, IntColumn ) VALUES ( 'Test_{}', {} );", count, count));
LibSQL+SQLServer: Introduce and use ResultOr<ValueType> The result of a SQL statement execution is either: 1. An error. 2. The list of rows inserted, deleted, selected, etc. (2) is currently represented by a combination of the Result class and the ResultSet list it holds. This worked okay, but issues start to arise when trying to use Result in non-statement contexts (for example, when introducing Result to SQL expression execution). What we really need is for Result to be a thin wrapper that represents both (1) and (2), and to not have any explicit members like a ResultSet. So this commit removes ResultSet from Result, and introduces ResultOr, which is just an alias for AK::ErrorOrr. Statement execution now returns ResultOr<ResultSet> instead of Result. This further opens the door for expression execution to return ResultOr<Value> in the future. Lastly, this moves some other context held by Result over to ResultSet. This includes the row count (which is really just the size of ResultSet) and the command for which the result is for.
2022-02-10 14:43:00 -05:00
EXPECT(result.size() == 1);
LibSQL: Introduce SELECT ... LIMIT xxx OFFSET yyy What it says on the tin.
2022-01-12 11:41:58 -05:00
}
auto result = execute(database, "SELECT TextColumn, IntColumn FROM TestSchema.TestTable ORDER BY IntColumn LIMIT 10 OFFSET 10;");
LibSQL+SQLServer: Introduce and use ResultOr<ValueType> The result of a SQL statement execution is either: 1. An error. 2. The list of rows inserted, deleted, selected, etc. (2) is currently represented by a combination of the Result class and the ResultSet list it holds. This worked okay, but issues start to arise when trying to use Result in non-statement contexts (for example, when introducing Result to SQL expression execution). What we really need is for Result to be a thin wrapper that represents both (1) and (2), and to not have any explicit members like a ResultSet. So this commit removes ResultSet from Result, and introduces ResultOr, which is just an alias for AK::ErrorOrr. Statement execution now returns ResultOr<ResultSet> instead of Result. This further opens the door for expression execution to return ResultOr<Value> in the future. Lastly, this moves some other context held by Result over to ResultSet. This includes the row count (which is really just the size of ResultSet) and the command for which the result is for.
2022-02-10 14:43:00 -05:00
EXPECT_EQ(result.size(), 10u);
EXPECT_EQ(result[0].row[1].to_int().value(), 10);
EXPECT_EQ(result[1].row[1].to_int().value(), 11);
EXPECT_EQ(result[2].row[1].to_int().value(), 12);
EXPECT_EQ(result[3].row[1].to_int().value(), 13);
EXPECT_EQ(result[4].row[1].to_int().value(), 14);
EXPECT_EQ(result[5].row[1].to_int().value(), 15);
EXPECT_EQ(result[6].row[1].to_int().value(), 16);
EXPECT_EQ(result[7].row[1].to_int().value(), 17);
EXPECT_EQ(result[8].row[1].to_int().value(), 18);
EXPECT_EQ(result[9].row[1].to_int().value(), 19);
LibSQL: Introduce SELECT ... LIMIT xxx OFFSET yyy What it says on the tin.
2022-01-12 11:41:58 -05:00
}
TEST_CASE(select_with_limit_out_of_bounds)
{
ScopeGuard guard([]() { unlink(db_name); });
auto database = SQL::Database::construct(db_name);
EXPECT(!database->open().is_error());
create_table(database);
for (auto count = 0; count < 100; count++) {
auto result = execute(database,
String::formatted("INSERT INTO TestSchema.TestTable ( TextColumn, IntColumn ) VALUES ( 'Test_{}', {} );", count, count));
LibSQL+SQLServer: Introduce and use ResultOr<ValueType> The result of a SQL statement execution is either: 1. An error. 2. The list of rows inserted, deleted, selected, etc. (2) is currently represented by a combination of the Result class and the ResultSet list it holds. This worked okay, but issues start to arise when trying to use Result in non-statement contexts (for example, when introducing Result to SQL expression execution). What we really need is for Result to be a thin wrapper that represents both (1) and (2), and to not have any explicit members like a ResultSet. So this commit removes ResultSet from Result, and introduces ResultOr, which is just an alias for AK::ErrorOrr. Statement execution now returns ResultOr<ResultSet> instead of Result. This further opens the door for expression execution to return ResultOr<Value> in the future. Lastly, this moves some other context held by Result over to ResultSet. This includes the row count (which is really just the size of ResultSet) and the command for which the result is for.
2022-02-10 14:43:00 -05:00
EXPECT(result.size() == 1);
LibSQL: Introduce SELECT ... LIMIT xxx OFFSET yyy What it says on the tin.
2022-01-12 11:41:58 -05:00
}
auto result = execute(database, "SELECT TextColumn, IntColumn FROM TestSchema.TestTable LIMIT 500;");
LibSQL+SQLServer: Introduce and use ResultOr<ValueType> The result of a SQL statement execution is either: 1. An error. 2. The list of rows inserted, deleted, selected, etc. (2) is currently represented by a combination of the Result class and the ResultSet list it holds. This worked okay, but issues start to arise when trying to use Result in non-statement contexts (for example, when introducing Result to SQL expression execution). What we really need is for Result to be a thin wrapper that represents both (1) and (2), and to not have any explicit members like a ResultSet. So this commit removes ResultSet from Result, and introduces ResultOr, which is just an alias for AK::ErrorOrr. Statement execution now returns ResultOr<ResultSet> instead of Result. This further opens the door for expression execution to return ResultOr<Value> in the future. Lastly, this moves some other context held by Result over to ResultSet. This includes the row count (which is really just the size of ResultSet) and the command for which the result is for.
2022-02-10 14:43:00 -05:00
EXPECT_EQ(result.size(), 100u);
LibSQL: Introduce SELECT ... LIMIT xxx OFFSET yyy What it says on the tin.
2022-01-12 11:41:58 -05:00
}
TEST_CASE(select_with_offset_out_of_bounds)
{
ScopeGuard guard([]() { unlink(db_name); });
auto database = SQL::Database::construct(db_name);
EXPECT(!database->open().is_error());
create_table(database);
for (auto count = 0; count < 100; count++) {
auto result = execute(database,
String::formatted("INSERT INTO TestSchema.TestTable ( TextColumn, IntColumn ) VALUES ( 'Test_{}', {} );", count, count));
LibSQL+SQLServer: Introduce and use ResultOr<ValueType> The result of a SQL statement execution is either: 1. An error. 2. The list of rows inserted, deleted, selected, etc. (2) is currently represented by a combination of the Result class and the ResultSet list it holds. This worked okay, but issues start to arise when trying to use Result in non-statement contexts (for example, when introducing Result to SQL expression execution). What we really need is for Result to be a thin wrapper that represents both (1) and (2), and to not have any explicit members like a ResultSet. So this commit removes ResultSet from Result, and introduces ResultOr, which is just an alias for AK::ErrorOrr. Statement execution now returns ResultOr<ResultSet> instead of Result. This further opens the door for expression execution to return ResultOr<Value> in the future. Lastly, this moves some other context held by Result over to ResultSet. This includes the row count (which is really just the size of ResultSet) and the command for which the result is for.
2022-02-10 14:43:00 -05:00
EXPECT(result.size() == 1);
LibSQL: Introduce SELECT ... LIMIT xxx OFFSET yyy What it says on the tin.
2022-01-12 11:41:58 -05:00
}
auto result = execute(database, "SELECT TextColumn, IntColumn FROM TestSchema.TestTable LIMIT 10 OFFSET 200;");
LibSQL+SQLServer: Introduce and use ResultOr<ValueType> The result of a SQL statement execution is either: 1. An error. 2. The list of rows inserted, deleted, selected, etc. (2) is currently represented by a combination of the Result class and the ResultSet list it holds. This worked okay, but issues start to arise when trying to use Result in non-statement contexts (for example, when introducing Result to SQL expression execution). What we really need is for Result to be a thin wrapper that represents both (1) and (2), and to not have any explicit members like a ResultSet. So this commit removes ResultSet from Result, and introduces ResultOr, which is just an alias for AK::ErrorOrr. Statement execution now returns ResultOr<ResultSet> instead of Result. This further opens the door for expression execution to return ResultOr<Value> in the future. Lastly, this moves some other context held by Result over to ResultSet. This includes the row count (which is really just the size of ResultSet) and the command for which the result is for.
2022-02-10 14:43:00 -05:00
EXPECT_EQ(result.size(), 0u);
LibSQL: Introduce SELECT ... LIMIT xxx OFFSET yyy What it says on the tin.
2022-01-12 11:41:58 -05:00
}
LibSQL: Implement DESCRIBE TABLE tests
2021-09-19 21:35:16 +02:00
TEST_CASE(describe_table)
{
ScopeGuard guard([]() { unlink(db_name); });
auto database = SQL::Database::construct(db_name);
EXPECT(!database->open().is_error());
create_table(database);
auto result = execute(database, "DESCRIBE TABLE TestSchema.TestTable;");
LibSQL+SQLServer: Introduce and use ResultOr<ValueType> The result of a SQL statement execution is either: 1. An error. 2. The list of rows inserted, deleted, selected, etc. (2) is currently represented by a combination of the Result class and the ResultSet list it holds. This worked okay, but issues start to arise when trying to use Result in non-statement contexts (for example, when introducing Result to SQL expression execution). What we really need is for Result to be a thin wrapper that represents both (1) and (2), and to not have any explicit members like a ResultSet. So this commit removes ResultSet from Result, and introduces ResultOr, which is just an alias for AK::ErrorOrr. Statement execution now returns ResultOr<ResultSet> instead of Result. This further opens the door for expression execution to return ResultOr<Value> in the future. Lastly, this moves some other context held by Result over to ResultSet. This includes the row count (which is really just the size of ResultSet) and the command for which the result is for.
2022-02-10 14:43:00 -05:00
EXPECT_EQ(result.size(), 2u);
EXPECT_EQ(result[0].row[0].to_string(), "TEXTCOLUMN");
EXPECT_EQ(result[0].row[1].to_string(), "text");
EXPECT_EQ(result[1].row[0].to_string(), "INTCOLUMN");
EXPECT_EQ(result[1].row[1].to_string(), "int");
LibSQL: Implement DESCRIBE TABLE tests
2021-09-19 21:35:16 +02:00
}
LibSQL+SQLServer: Bare bones INSERT and SELECT statements This patch provides very basic, bare bones implementations of the INSERT and SELECT statements. They are *very* limited: - The only variant of the INSERT statement that currently works is SELECT INTO schema.table (column1, column2, ....) VALUES (value11, value21, ...), (value12, value22, ...), ... where the values are literals. - The SELECT statement is even more limited, and is only provided to allow verification of the INSERT statement. The only form implemented is: SELECT * FROM schema.table These statements required a bit of change in the Statement::execute API. Originally execute only received a Database object as parameter. This is not enough; we now pass an ExecutionContext object which contains the Database, the current result set, and the last Tuple read from the database. This object will undoubtedly evolve over time. This API change dragged SQLServer::SQLStatement into the patch. Another API addition is Expression::evaluate. This method is, unsurprisingly, used to evaluate expressions, like the values in the INSERT statement. Finally, a new test file is added: TestSqlStatementExecution, which tests the currently implemented statements. As the number and flavour of implemented statements grows, this test file will probably have to be restructured.
2021-07-19 19:48:46 -04:00
}
Reference in a new issue Copy permalink