Stowage/ladybird
2
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-12-08 06:09:58 +00:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Tests/LibSQL/TestSqlStatementExecution.cpp

890 lines
34 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>
LibSQL: Convert binary SQL operations to be fallible Now that expression evaluation can use TRY, we can allow binary operator methods to fail as well. This also fixes a few instances of converting a Value to a double when we meant to convert to an integer.
2022-02-11 10:23:20 -05:00
#include <AK/QuickSort.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 <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 {
Everywhere: Run clang-format
2022-04-01 20:58:27 +03:00
constexpr char const* db_name = "/tmp/test.db";
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+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());
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());
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+SQLServer: Return a NonnullRefPtr from Database::get_table Database::get_table currently either returns a RefPtr to an existing table, a nullptr if the table doesn't exist, or an Error if some internal error occured. Change this to return a NonnullRefPtr to an exisiting table, or a SQL::Result with any error, including if the table was not found. Callers can then handle that specific error code if they want. Returning a NonnullRefPtr will enable some further cleanup. This had some fallout of needing to change some other methods' return types from AK::ErrorOr to SQL::Result so that TRY may continue to be used.
2022-11-29 08:47:22 -05:00
auto table = MUST(database->get_table("TESTSCHEMA", "TESTTABLE"));
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+SQLServer: Return a NonnullRefPtr from Database::get_table Database::get_table currently either returns a RefPtr to an existing table, a nullptr if the table doesn't exist, or an Error if some internal error occured. Change this to return a NonnullRefPtr to an exisiting table, or a SQL::Result with any error, including if the table was not found. Callers can then handle that specific error code if they want. Returning a NonnullRefPtr will enable some further cleanup. This had some fallout of needing to change some other methods' return types from AK::ErrorOr to SQL::Result so that TRY may continue to be used.
2022-11-29 08:47:22 -05:00
auto table = MUST(database->get_table("TESTSCHEMA", "TESTTABLE"));
auto rows_or_error = database->select_all(*table);
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(!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: Convert binary SQL operations to be fallible Now that expression evaluation can use TRY, we can allow binary operator methods to fail as well. This also fixes a few instances of converting a Value to a double when we meant to convert to an integer.
2022-02-11 10:23:20 -05:00
TEST_CASE(binary_operator_execution)
{
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 < 10; ++count) {
auto result = execute(database, String::formatted("INSERT INTO TestSchema.TestTable VALUES ( 'T{}', {} );", count, count));
EXPECT_EQ(result.size(), 1u);
}
auto compare_result = [](SQL::ResultSet const& result, Vector<int> const& expected) {
EXPECT_EQ(result.command(), SQL::SQLCommand::Select);
EXPECT_EQ(result.size(), expected.size());
Vector<int> result_values;
result_values.ensure_capacity(result.size());
for (size_t i = 0; i < result.size(); ++i) {
auto const& result_row = result.at(i).row;
EXPECT_EQ(result_row.size(), 1u);
auto result_column = result_row[0].to_int();
result_values.append(result_column.value());
}
quick_sort(result_values);
EXPECT_EQ(result_values, expected);
};
auto result = execute(database, "SELECT IntColumn FROM TestSchema.TestTable WHERE ((IntColumn + 1) < 5);");
compare_result(result, { 0, 1, 2, 3 });
result = execute(database, "SELECT IntColumn FROM TestSchema.TestTable WHERE ((IntColumn + 1) <= 5);");
compare_result(result, { 0, 1, 2, 3, 4 });
result = execute(database, "SELECT IntColumn FROM TestSchema.TestTable WHERE ((IntColumn - 1) > 4);");
compare_result(result, { 6, 7, 8, 9 });
result = execute(database, "SELECT IntColumn FROM TestSchema.TestTable WHERE ((IntColumn - 1) >= 4);");
compare_result(result, { 5, 6, 7, 8, 9 });
result = execute(database, "SELECT IntColumn FROM TestSchema.TestTable WHERE ((IntColumn * 2) < 10);");
compare_result(result, { 0, 1, 2, 3, 4 });
result = execute(database, "SELECT IntColumn FROM TestSchema.TestTable WHERE ((IntColumn * 2) <= 10);");
compare_result(result, { 0, 1, 2, 3, 4, 5 });
result = execute(database, "SELECT IntColumn FROM TestSchema.TestTable WHERE ((IntColumn / 3) > 2);");
compare_result(result, { 7, 8, 9 });
result = execute(database, "SELECT IntColumn FROM TestSchema.TestTable WHERE ((IntColumn / 3) >= 2);");
compare_result(result, { 6, 7, 8, 9 });
result = execute(database, "SELECT IntColumn FROM TestSchema.TestTable WHERE ((IntColumn % 2) = 0);");
compare_result(result, { 0, 2, 4, 6, 8 });
result = execute(database, "SELECT IntColumn FROM TestSchema.TestTable WHERE ((IntColumn % 2) = 1);");
compare_result(result, { 1, 3, 5, 7, 9 });
result = execute(database, "SELECT IntColumn FROM TestSchema.TestTable WHERE ((1 << IntColumn) <= 32);");
compare_result(result, { 0, 1, 2, 3, 4, 5 });
result = execute(database, "SELECT IntColumn FROM TestSchema.TestTable WHERE ((1024 >> IntColumn) >= 32);");
compare_result(result, { 0, 1, 2, 3, 4, 5 });
result = execute(database, "SELECT IntColumn FROM TestSchema.TestTable WHERE ((IntColumn | 1) != IntColumn);");
compare_result(result, { 0, 2, 4, 6, 8 });
result = execute(database, "SELECT IntColumn FROM TestSchema.TestTable WHERE ((IntColumn & 1) = 1);");
compare_result(result, { 1, 3, 5, 7, 9 });
}
TEST_CASE(binary_operator_failure)
{
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 < 10; ++count) {
auto result = execute(database, String::formatted("INSERT INTO TestSchema.TestTable VALUES ( 'T{}', {} );", count, count));
EXPECT_EQ(result.size(), 1u);
}
auto expect_failure = [](auto result, auto op) {
EXPECT(result.is_error());
auto error = result.release_error();
EXPECT_EQ(error.error(), SQL::SQLErrorCode::NumericOperatorTypeMismatch);
auto message = String::formatted("NumericOperatorTypeMismatch: Cannot apply '{}' operator to non-numeric operands", op);
EXPECT_EQ(error.error_string(), message);
};
auto result = try_execute(database, "SELECT * FROM TestSchema.TestTable WHERE ((IntColumn + TextColumn) < 5);");
expect_failure(move(result), '+');
result = try_execute(database, "SELECT * FROM TestSchema.TestTable WHERE ((IntColumn - TextColumn) < 5);");
expect_failure(move(result), '-');
result = try_execute(database, "SELECT * FROM TestSchema.TestTable WHERE ((IntColumn * TextColumn) < 5);");
expect_failure(move(result), '*');
result = try_execute(database, "SELECT * FROM TestSchema.TestTable WHERE ((IntColumn / TextColumn) < 5);");
expect_failure(move(result), '/');
result = try_execute(database, "SELECT * FROM TestSchema.TestTable WHERE ((IntColumn % TextColumn) < 5);");
expect_failure(move(result), '%');
result = try_execute(database, "SELECT * FROM TestSchema.TestTable WHERE ((IntColumn << TextColumn) < 5);");
expect_failure(move(result), "<<"sv);
result = try_execute(database, "SELECT * FROM TestSchema.TestTable WHERE ((IntColumn >> TextColumn) < 5);");
expect_failure(move(result), ">>"sv);
result = try_execute(database, "SELECT * FROM TestSchema.TestTable WHERE ((IntColumn | TextColumn) < 5);");
expect_failure(move(result), '|');
result = try_execute(database, "SELECT * FROM TestSchema.TestTable WHERE ((IntColumn & TextColumn) < 5);");
expect_failure(move(result), '&');
}
LibSQL: Fix BTree corruption in `TreeNode::split` After splitting a node, the new node was written to the same pointer as the current node - probably a copy / paste error. This new code requires a `.pointer() -> u32` to exist on the object to be serialized, preventing this issue from happening again. Fixes #15844.
2022-11-26 01:17:43 +01:00
TEST_CASE(describe_large_table_after_persist)
{
ScopeGuard guard([]() { unlink(db_name); });
{
auto database = SQL::Database::construct(db_name);
EXPECT(!database->open().is_error());
auto result = execute(database, "CREATE TABLE Cookies ( name TEXT, value TEXT, same_site INTEGER, creation_time INTEGER, last_access_time INTEGER, expiry_time INTEGER, domain TEXT, path TEXT, secure INTEGER, http_only INTEGER, host_only INTEGER, persistent INTEGER );");
EXPECT_EQ(result.command(), SQL::SQLCommand::Create);
}
{
auto database = SQL::Database::construct(db_name);
EXPECT(!database->open().is_error());
auto result = execute(database, "DESCRIBE TABLE Cookies;");
EXPECT_EQ(result.size(), 12u);
}
}
LibSQL: Partially implement the DELETE command This implements enough to delete rows filtered by a WHERE clause.
2022-11-28 07:49:03 -05:00
TEST_CASE(delete_single_row)
{
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 < 10; ++count) {
auto result = execute(database, String::formatted("INSERT INTO TestSchema.TestTable VALUES ( 'T{}', {} );", count, count));
EXPECT_EQ(result.size(), 1u);
}
auto result = execute(database, "SELECT * FROM TestSchema.TestTable;");
EXPECT_EQ(result.size(), 10u);
}
{
auto database = SQL::Database::construct(db_name);
EXPECT(!database->open().is_error());
execute(database, "DELETE FROM TestSchema.TestTable WHERE (IntColumn = 4);");
auto result = execute(database, "SELECT IntColumn FROM TestSchema.TestTable ORDER BY IntColumn;");
EXPECT_EQ(result.size(), 9u);
for (auto i = 0u; i < 4; ++i)
EXPECT_EQ(result[i].row[0], i);
for (auto i = 5u; i < 9; ++i)
EXPECT_EQ(result[i].row[0], i + 1);
}
{
auto database = SQL::Database::construct(db_name);
EXPECT(!database->open().is_error());
auto result = execute(database, "SELECT IntColumn FROM TestSchema.TestTable ORDER BY IntColumn;");
EXPECT_EQ(result.size(), 9u);
for (auto i = 0u; i < 4; ++i)
EXPECT_EQ(result[i].row[0], i);
for (auto i = 5u; i < 9; ++i)
EXPECT_EQ(result[i].row[0], i + 1);
}
}
TEST_CASE(delete_multiple_rows)
{
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 < 10; ++count) {
auto result = execute(database, String::formatted("INSERT INTO TestSchema.TestTable VALUES ( 'T{}', {} );", count, count));
EXPECT_EQ(result.size(), 1u);
}
auto result = execute(database, "SELECT * FROM TestSchema.TestTable;");
EXPECT_EQ(result.size(), 10u);
}
{
auto database = SQL::Database::construct(db_name);
EXPECT(!database->open().is_error());
execute(database, "DELETE FROM TestSchema.TestTable WHERE (IntColumn >= 4);");
auto result = execute(database, "SELECT IntColumn FROM TestSchema.TestTable ORDER BY IntColumn;");
EXPECT_EQ(result.size(), 4u);
for (auto i = 0u; i < result.size(); ++i)
EXPECT_EQ(result[i].row[0], i);
}
{
auto database = SQL::Database::construct(db_name);
EXPECT(!database->open().is_error());
auto result = execute(database, "SELECT IntColumn FROM TestSchema.TestTable ORDER BY IntColumn;");
EXPECT_EQ(result.size(), 4u);
for (auto i = 0u; i < result.size(); ++i)
EXPECT_EQ(result[i].row[0], i);
}
}
TEST_CASE(delete_all_rows)
{
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 < 10; ++count) {
auto result = execute(database, String::formatted("INSERT INTO TestSchema.TestTable VALUES ( 'T{}', {} );", count, count));
EXPECT_EQ(result.size(), 1u);
}
auto result = execute(database, "SELECT * FROM TestSchema.TestTable;");
EXPECT_EQ(result.size(), 10u);
}
{
auto database = SQL::Database::construct(db_name);
EXPECT(!database->open().is_error());
execute(database, "DELETE FROM TestSchema.TestTable;");
auto result = execute(database, "SELECT * FROM TestSchema.TestTable;");
EXPECT(result.is_empty());
}
{
auto database = SQL::Database::construct(db_name);
EXPECT(!database->open().is_error());
auto result = execute(database, "SELECT * FROM TestSchema.TestTable;");
EXPECT(result.is_empty());
}
}
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