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

1064 lines
40 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
Everywhere: Rename {Deprecated => Byte}String This commit un-deprecates DeprecatedString, and repurposes it as a byte string. As the null state has already been removed, there are no other particularly hairy blockers in repurposing this type as a byte string (what it _really_ is). This commit is auto-generated: $ xs=$(ack -l \bDeprecatedString\b\|deprecated_string AK Userland \ Meta Ports Ladybird Tests Kernel) $ perl -pie 's/\bDeprecatedString\b/ByteString/g; s/deprecated_string/byte_string/g' $xs $ clang-format --style=file -i \ $(git diff --name-only | grep \.cpp\|\.h) $ gn format $(git ls-files '*.gn' '*.gni')
2023-12-16 17:49:34 +03:30
SQL::ResultOr<SQL::ResultSet> try_execute(NonnullRefPtr<SQL::Database> database, ByteString const& sql, Vector<SQL::Value> placeholder_values = {})
LibSQL+SQLServer: Bare bones INSERT and SELECT statements This patch provides very basic, bare bones implementations of the INSERT and SELECT statements. They are *very* limited: - The only variant of the INSERT statement that currently works is SELECT INTO schema.table (column1, column2, ....) VALUES (value11, value21, ...), (value12, value22, ...), ... where the values are literals. - The SELECT statement is even more limited, and is only provided to allow verification of the INSERT statement. The only form implemented is: SELECT * FROM schema.table These statements required a bit of change in the Statement::execute API. Originally execute only received a Database object as parameter. This is not enough; we now pass an ExecutionContext object which contains the Database, the current result set, and the last Tuple read from the database. This object will undoubtedly evolve over time. This API change dragged SQLServer::SQLStatement into the patch. Another API addition is Expression::evaluate. This method is, unsurprisingly, used to evaluate expressions, like the values in the INSERT statement. Finally, a new test file is added: TestSqlStatementExecution, which tests the currently implemented statements. As the number and flavour of implemented statements grows, this test file will probably have to be restructured.
2021-07-19 19:48:46 -04:00
{
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: Rename {Deprecated => Byte}String This commit un-deprecates DeprecatedString, and repurposes it as a byte string. As the null state has already been removed, there are no other particularly hairy blockers in repurposing this type as a byte string (what it _really_ is). This commit is auto-generated: $ xs=$(ack -l \bDeprecatedString\b\|deprecated_string AK Userland \ Meta Ports Ladybird Tests Kernel) $ perl -pie 's/\bDeprecatedString\b/ByteString/g; s/deprecated_string/byte_string/g' $xs $ clang-format --style=file -i \ $(git diff --name-only | grep \.cpp\|\.h) $ gn format $(git ls-files '*.gn' '*.gni')
2023-12-16 17:49:34 +03:30
outln("{}", parser.errors()[0].to_byte_string());
LibSQL: Parse and execute sequential placeholder values This partially implements SQLite's bind-parameter expression to support indicating placeholder values in a SQL statement. For example: INSERT INTO table VALUES (42, ?); In the above statement, the '?' identifier is a placeholder. This will allow clients to compile statements a single time while running those statements any number of times with different placeholder values. Further, this will help mitigate SQL injection attacks.
2022-12-01 22:20:55 -05:00
return statement->execute(move(database), placeholder_values);
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
}
Everywhere: Rename {Deprecated => Byte}String This commit un-deprecates DeprecatedString, and repurposes it as a byte string. As the null state has already been removed, there are no other particularly hairy blockers in repurposing this type as a byte string (what it _really_ is). This commit is auto-generated: $ xs=$(ack -l \bDeprecatedString\b\|deprecated_string AK Userland \ Meta Ports Ladybird Tests Kernel) $ perl -pie 's/\bDeprecatedString\b/ByteString/g; s/deprecated_string/byte_string/g' $xs $ clang-format --style=file -i \ $(git diff --name-only | grep \.cpp\|\.h) $ gn format $(git ls-files '*.gn' '*.gni')
2023-12-16 17:49:34 +03:30
SQL::ResultSet execute(NonnullRefPtr<SQL::Database> database, ByteString const& sql, Vector<SQL::Value> placeholder_values = {})
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
{
LibSQL: Parse and execute sequential placeholder values This partially implements SQLite's bind-parameter expression to support indicating placeholder values in a SQL statement. For example: INSERT INTO table VALUES (42, ?); In the above statement, the '?' identifier is a placeholder. This will allow clients to compile statements a single time while running those statements any number of times with different placeholder values. Further, this will help mitigate SQL injection attacks.
2022-12-01 22:20:55 -05:00
auto result = try_execute(move(database), sql, move(placeholder_values));
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
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
}
LibSQL: Parse and execute sequential placeholder values This partially implements SQLite's bind-parameter expression to support indicating placeholder values in a SQL statement. For example: INSERT INTO table VALUES (42, ?); In the above statement, the '?' identifier is a placeholder. This will allow clients to compile statements a single time while running those statements any number of times with different placeholder values. Further, this will help mitigate SQL injection attacks.
2022-12-01 22:20:55 -05:00
template<typename... Args>
Vector<SQL::Value> placeholders(Args&&... args)
{
return { SQL::Value(forward<Args>(args))... };
}
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); });
LibSQL+SQLServer: Remove Core::EventReceiver parent from SQL::Database This relationship was only used to provide factory methods for the database.
2023-08-07 11:03:42 -04:00
auto database = MUST(SQL::Database::create(db_name));
Tests: Prefer TRY_OR_FAIL() and MUST() over EXPECT(!.is_error()) Note that in some cases (in particular SQL::Result and PDFErrorOr), there is no Formatter defined for the error type, hence TRY_OR_FAIL cannot work as-is. Furthermore, this commit leaves untouched the places where MUST could be replaced by TRY_OR_FAIL. Inspired by: https://github.com/SerenityOS/serenity/pull/18710#discussion_r1186892445
2023-05-07 20:14:06 +02:00
MUST(database->open());
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);
Tests: Prefer TRY_OR_FAIL() and MUST() over EXPECT(!.is_error()) Note that in some cases (in particular SQL::Result and PDFErrorOr), there is no Formatter defined for the error type, hence TRY_OR_FAIL cannot work as-is. Furthermore, this commit leaves untouched the places where MUST could be replaced by TRY_OR_FAIL. Inspired by: https://github.com/SerenityOS/serenity/pull/18710#discussion_r1186892445
2023-05-07 20:14:06 +02:00
auto schema = MUST(database->get_schema("TESTSCHEMA"));
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); });
LibSQL+SQLServer: Remove Core::EventReceiver parent from SQL::Database This relationship was only used to provide factory methods for the database.
2023-08-07 11:03:42 -04:00
auto database = MUST(SQL::Database::create(db_name));
Tests: Prefer TRY_OR_FAIL() and MUST() over EXPECT(!.is_error()) Note that in some cases (in particular SQL::Result and PDFErrorOr), there is no Formatter defined for the error type, hence TRY_OR_FAIL cannot work as-is. Furthermore, this commit leaves untouched the places where MUST could be replaced by TRY_OR_FAIL. Inspired by: https://github.com/SerenityOS/serenity/pull/18710#discussion_r1186892445
2023-05-07 20:14:06 +02:00
MUST(database->open());
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);
Tests: Prefer TRY_OR_FAIL() and MUST() over EXPECT(!.is_error()) Note that in some cases (in particular SQL::Result and PDFErrorOr), there is no Formatter defined for the error type, hence TRY_OR_FAIL cannot work as-is. Furthermore, this commit leaves untouched the places where MUST could be replaced by TRY_OR_FAIL. Inspired by: https://github.com/SerenityOS/serenity/pull/18710#discussion_r1186892445
2023-05-07 20:14:06 +02: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
}
TEST_CASE(insert_into_table)
{
ScopeGuard guard([]() { unlink(db_name); });
LibSQL+SQLServer: Remove Core::EventReceiver parent from SQL::Database This relationship was only used to provide factory methods for the database.
2023-08-07 11:03:42 -04:00
auto database = MUST(SQL::Database::create(db_name));
Tests: Prefer TRY_OR_FAIL() and MUST() over EXPECT(!.is_error()) Note that in some cases (in particular SQL::Result and PDFErrorOr), there is no Formatter defined for the error type, hence TRY_OR_FAIL cannot work as-is. Furthermore, this commit leaves untouched the places where MUST could be replaced by TRY_OR_FAIL. Inspired by: https://github.com/SerenityOS/serenity/pull/18710#discussion_r1186892445
2023-05-07 20:14:06 +02:00
MUST(database->open());
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;
Tests: Prefer TRY_OR_FAIL() and MUST() over EXPECT(!.is_error()) Note that in some cases (in particular SQL::Result and PDFErrorOr), there is no Formatter defined for the error type, hence TRY_OR_FAIL cannot work as-is. Furthermore, this commit leaves untouched the places where MUST could be replaced by TRY_OR_FAIL. Inspired by: https://github.com/SerenityOS/serenity/pull/18710#discussion_r1186892445
2023-05-07 20:14:06 +02:00
auto rows = TRY_OR_FAIL(database->select_all(*table));
for (auto& row : rows) {
Everywhere: Rename {Deprecated => Byte}String This commit un-deprecates DeprecatedString, and repurposes it as a byte string. As the null state has already been removed, there are no other particularly hairy blockers in repurposing this type as a byte string (what it _really_ is). This commit is auto-generated: $ xs=$(ack -l \bDeprecatedString\b\|deprecated_string AK Userland \ Meta Ports Ladybird Tests Kernel) $ perl -pie 's/\bDeprecatedString\b/ByteString/g; s/deprecated_string/byte_string/g' $xs $ clang-format --style=file -i \ $(git diff --name-only | grep \.cpp\|\.h) $ gn format $(git ls-files '*.gn' '*.gni')
2023-12-16 17:49:34 +03:30
EXPECT_EQ(row["TEXTCOLUMN"].to_byte_string(), "Test");
LibSQL: Support 64-bit integer values and handle overflow errors Currently, integers are stored in LibSQL as 32-bit signed integers, even if the provided type is unsigned. This resulted in a series of unchecked unsigned-to-signed conversions, and prevented storing 64-bit values. Further, mathematical operations were performed without similar checks, and without checking for overflow. This changes SQL::Value to behave like SQLite for INTEGER types. In SQLite, the INTEGER type does not imply a size or signedness of the underlying type. Instead, SQLite determines on-the-fly what type is needed as values are created and updated. To do so, the SQL::Value variant can now hold an i64 or u64 integer. If a specific type is requested, invalid conversions are now explictly an error (e.g. converting a stored -1 to a u64 will fail). When binary mathematical operations are performed, we now try to coerce the RHS value to a type that works with the LHS value, failing the operation if that isn't possible. Any overflow or invalid operation (e.g. bitshifting a 64-bit value by more than 64 bytes) is an error.
2022-12-11 11:44:11 -05:00
EXPECT_EQ(row["INTCOLUMN"].to_int<i32>(), 42);
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
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); });
LibSQL+SQLServer: Remove Core::EventReceiver parent from SQL::Database This relationship was only used to provide factory methods for the database.
2023-08-07 11:03:42 -04:00
auto database = MUST(SQL::Database::create(db_name));
Tests: Prefer TRY_OR_FAIL() and MUST() over EXPECT(!.is_error()) Note that in some cases (in particular SQL::Result and PDFErrorOr), there is no Formatter defined for the error type, hence TRY_OR_FAIL cannot work as-is. Furthermore, this commit leaves untouched the places where MUST could be replaced by TRY_OR_FAIL. Inspired by: https://github.com/SerenityOS/serenity/pull/18710#discussion_r1186892445
2023-05-07 20:14:06 +02:00
MUST(database->open());
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); });
LibSQL+SQLServer: Remove Core::EventReceiver parent from SQL::Database This relationship was only used to provide factory methods for the database.
2023-08-07 11:03:42 -04:00
auto database = MUST(SQL::Database::create(db_name));
Tests: Prefer TRY_OR_FAIL() and MUST() over EXPECT(!.is_error()) Note that in some cases (in particular SQL::Result and PDFErrorOr), there is no Formatter defined for the error type, hence TRY_OR_FAIL cannot work as-is. Furthermore, this commit leaves untouched the places where MUST could be replaced by TRY_OR_FAIL. Inspired by: https://github.com/SerenityOS/serenity/pull/18710#discussion_r1186892445
2023-05-07 20:14:06 +02:00
MUST(database->open());
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); });
LibSQL+SQLServer: Remove Core::EventReceiver parent from SQL::Database This relationship was only used to provide factory methods for the database.
2023-08-07 11:03:42 -04:00
auto database = MUST(SQL::Database::create(db_name));
Tests: Prefer TRY_OR_FAIL() and MUST() over EXPECT(!.is_error()) Note that in some cases (in particular SQL::Result and PDFErrorOr), there is no Formatter defined for the error type, hence TRY_OR_FAIL cannot work as-is. Furthermore, this commit leaves untouched the places where MUST could be replaced by TRY_OR_FAIL. Inspired by: https://github.com/SerenityOS/serenity/pull/18710#discussion_r1186892445
2023-05-07 20:14:06 +02:00
MUST(database->open());
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); });
LibSQL+SQLServer: Remove Core::EventReceiver parent from SQL::Database This relationship was only used to provide factory methods for the database.
2023-08-07 11:03:42 -04:00
auto database = MUST(SQL::Database::create(db_name));
Tests: Prefer TRY_OR_FAIL() and MUST() over EXPECT(!.is_error()) Note that in some cases (in particular SQL::Result and PDFErrorOr), there is no Formatter defined for the error type, hence TRY_OR_FAIL cannot work as-is. Furthermore, this commit leaves untouched the places where MUST could be replaced by TRY_OR_FAIL. Inspired by: https://github.com/SerenityOS/serenity/pull/18710#discussion_r1186892445
2023-05-07 20:14:06 +02:00
MUST(database->open());
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
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); });
LibSQL+SQLServer: Remove Core::EventReceiver parent from SQL::Database This relationship was only used to provide factory methods for the database.
2023-08-07 11:03:42 -04:00
auto database = MUST(SQL::Database::create(db_name));
Tests: Prefer TRY_OR_FAIL() and MUST() over EXPECT(!.is_error()) Note that in some cases (in particular SQL::Result and PDFErrorOr), there is no Formatter defined for the error type, hence TRY_OR_FAIL cannot work as-is. Furthermore, this commit leaves untouched the places where MUST could be replaced by TRY_OR_FAIL. Inspired by: https://github.com/SerenityOS/serenity/pull/18710#discussion_r1186892445
2023-05-07 20:14:06 +02:00
MUST(database->open());
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
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); });
LibSQL+SQLServer: Remove Core::EventReceiver parent from SQL::Database This relationship was only used to provide factory methods for the database.
2023-08-07 11:03:42 -04:00
auto database = MUST(SQL::Database::create(db_name));
Tests: Prefer TRY_OR_FAIL() and MUST() over EXPECT(!.is_error()) Note that in some cases (in particular SQL::Result and PDFErrorOr), there is no Formatter defined for the error type, hence TRY_OR_FAIL cannot work as-is. Furthermore, this commit leaves untouched the places where MUST could be replaced by TRY_OR_FAIL. Inspired by: https://github.com/SerenityOS/serenity/pull/18710#discussion_r1186892445
2023-05-07 20:14:06 +02:00
MUST(database->open());
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"));
Tests: Prefer TRY_OR_FAIL() and MUST() over EXPECT(!.is_error()) Note that in some cases (in particular SQL::Result and PDFErrorOr), there is no Formatter defined for the error type, hence TRY_OR_FAIL cannot work as-is. Furthermore, this commit leaves untouched the places where MUST could be replaced by TRY_OR_FAIL. Inspired by: https://github.com/SerenityOS/serenity/pull/18710#discussion_r1186892445
2023-05-07 20:14:06 +02:00
auto rows = TRY_OR_FAIL(database->select_all(*table));
EXPECT_EQ(rows.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: Parse and execute sequential placeholder values This partially implements SQLite's bind-parameter expression to support indicating placeholder values in a SQL statement. For example: INSERT INTO table VALUES (42, ?); In the above statement, the '?' identifier is a placeholder. This will allow clients to compile statements a single time while running those statements any number of times with different placeholder values. Further, this will help mitigate SQL injection attacks.
2022-12-01 22:20:55 -05:00
TEST_CASE(insert_with_placeholders)
{
ScopeGuard guard([]() { unlink(db_name); });
LibSQL+SQLServer: Remove Core::EventReceiver parent from SQL::Database This relationship was only used to provide factory methods for the database.
2023-08-07 11:03:42 -04:00
auto database = MUST(SQL::Database::create(db_name));
Tests: Prefer TRY_OR_FAIL() and MUST() over EXPECT(!.is_error()) Note that in some cases (in particular SQL::Result and PDFErrorOr), there is no Formatter defined for the error type, hence TRY_OR_FAIL cannot work as-is. Furthermore, this commit leaves untouched the places where MUST could be replaced by TRY_OR_FAIL. Inspired by: https://github.com/SerenityOS/serenity/pull/18710#discussion_r1186892445
2023-05-07 20:14:06 +02:00
MUST(database->open());
LibSQL: Parse and execute sequential placeholder values This partially implements SQLite's bind-parameter expression to support indicating placeholder values in a SQL statement. For example: INSERT INTO table VALUES (42, ?); In the above statement, the '?' identifier is a placeholder. This will allow clients to compile statements a single time while running those statements any number of times with different placeholder values. Further, this will help mitigate SQL injection attacks.
2022-12-01 22:20:55 -05:00
create_table(database);
{
auto result = try_execute(database, "INSERT INTO TestSchema.TestTable VALUES (?, ?);");
EXPECT(result.is_error());
EXPECT_EQ(result.error().error(), SQL::SQLErrorCode::InvalidNumberOfPlaceholderValues);
result = try_execute(database, "INSERT INTO TestSchema.TestTable VALUES (?, ?);", placeholders("Test_1"sv));
EXPECT(result.is_error());
EXPECT_EQ(result.error().error(), SQL::SQLErrorCode::InvalidNumberOfPlaceholderValues);
result = try_execute(database, "INSERT INTO TestSchema.TestTable VALUES (?, ?);", placeholders(42, 42));
EXPECT(result.is_error());
EXPECT_EQ(result.error().error(), SQL::SQLErrorCode::InvalidValueType);
result = try_execute(database, "INSERT INTO TestSchema.TestTable VALUES (?, ?);", placeholders("Test_1"sv, "Test_2"sv));
EXPECT(result.is_error());
EXPECT_EQ(result.error().error(), SQL::SQLErrorCode::InvalidValueType);
}
{
auto result = execute(database, "INSERT INTO TestSchema.TestTable VALUES (?, ?);", placeholders("Test_1"sv, 42));
EXPECT_EQ(result.size(), 1u);
result = execute(database, "SELECT TextColumn, IntColumn FROM TestSchema.TestTable ORDER BY TextColumn;");
EXPECT_EQ(result.size(), 1u);
EXPECT_EQ(result[0].row[0], "Test_1"sv);
EXPECT_EQ(result[0].row[1], 42);
}
{
auto result = execute(database, "INSERT INTO TestSchema.TestTable VALUES (?, ?), (?, ?);", placeholders("Test_2"sv, 43, "Test_3"sv, 44));
EXPECT_EQ(result.size(), 2u);
result = execute(database, "SELECT TextColumn, IntColumn FROM TestSchema.TestTable ORDER BY TextColumn;");
EXPECT_EQ(result.size(), 3u);
EXPECT_EQ(result[0].row[0], "Test_1"sv);
EXPECT_EQ(result[0].row[1], 42);
EXPECT_EQ(result[1].row[0], "Test_2"sv);
EXPECT_EQ(result[1].row[1], 43);
EXPECT_EQ(result[2].row[0], "Test_3"sv);
EXPECT_EQ(result[2].row[1], 44);
}
}
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); });
LibSQL+SQLServer: Remove Core::EventReceiver parent from SQL::Database This relationship was only used to provide factory methods for the database.
2023-08-07 11:03:42 -04:00
auto database = MUST(SQL::Database::create(db_name));
Tests: Prefer TRY_OR_FAIL() and MUST() over EXPECT(!.is_error()) Note that in some cases (in particular SQL::Result and PDFErrorOr), there is no Formatter defined for the error type, hence TRY_OR_FAIL cannot work as-is. Furthermore, this commit leaves untouched the places where MUST could be replaced by TRY_OR_FAIL. Inspired by: https://github.com/SerenityOS/serenity/pull/18710#discussion_r1186892445
2023-05-07 20:14:06 +02:00
MUST(database->open());
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
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); });
LibSQL+SQLServer: Remove Core::EventReceiver parent from SQL::Database This relationship was only used to provide factory methods for the database.
2023-08-07 11:03:42 -04:00
auto database = MUST(SQL::Database::create(db_name));
Tests: Prefer TRY_OR_FAIL() and MUST() over EXPECT(!.is_error()) Note that in some cases (in particular SQL::Result and PDFErrorOr), there is no Formatter defined for the error type, hence TRY_OR_FAIL cannot work as-is. Furthermore, this commit leaves untouched the places where MUST could be replaced by TRY_OR_FAIL. Inspired by: https://github.com/SerenityOS/serenity/pull/18710#discussion_r1186892445
2023-05-07 20:14:06 +02:00
MUST(database->open());
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); });
LibSQL+SQLServer: Remove Core::EventReceiver parent from SQL::Database This relationship was only used to provide factory methods for the database.
2023-08-07 11:03:42 -04:00
auto database = MUST(SQL::Database::create(db_name));
Tests: Prefer TRY_OR_FAIL() and MUST() over EXPECT(!.is_error()) Note that in some cases (in particular SQL::Result and PDFErrorOr), there is no Formatter defined for the error type, hence TRY_OR_FAIL cannot work as-is. Furthermore, this commit leaves untouched the places where MUST could be replaced by TRY_OR_FAIL. Inspired by: https://github.com/SerenityOS/serenity/pull/18710#discussion_r1186892445
2023-05-07 20:14:06 +02:00
MUST(database->open());
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); });
LibSQL+SQLServer: Remove Core::EventReceiver parent from SQL::Database This relationship was only used to provide factory methods for the database.
2023-08-07 11:03:42 -04:00
auto database = MUST(SQL::Database::create(db_name));
Tests: Prefer TRY_OR_FAIL() and MUST() over EXPECT(!.is_error()) Note that in some cases (in particular SQL::Result and PDFErrorOr), there is no Formatter defined for the error type, hence TRY_OR_FAIL cannot work as-is. Furthermore, this commit leaves untouched the places where MUST could be replaced by TRY_OR_FAIL. Inspired by: https://github.com/SerenityOS/serenity/pull/18710#discussion_r1186892445
2023-05-07 20:14:06 +02:00
MUST(database->open());
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); });
LibSQL+SQLServer: Remove Core::EventReceiver parent from SQL::Database This relationship was only used to provide factory methods for the database.
2023-08-07 11:03:42 -04:00
auto database = MUST(SQL::Database::create(db_name));
Tests: Prefer TRY_OR_FAIL() and MUST() over EXPECT(!.is_error()) Note that in some cases (in particular SQL::Result and PDFErrorOr), there is no Formatter defined for the error type, hence TRY_OR_FAIL cannot work as-is. Furthermore, this commit leaves untouched the places where MUST could be replaced by TRY_OR_FAIL. Inspired by: https://github.com/SerenityOS/serenity/pull/18710#discussion_r1186892445
2023-05-07 20:14:06 +02:00
MUST(database->open());
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: Support 64-bit integer values and handle overflow errors Currently, integers are stored in LibSQL as 32-bit signed integers, even if the provided type is unsigned. This resulted in a series of unchecked unsigned-to-signed conversions, and prevented storing 64-bit values. Further, mathematical operations were performed without similar checks, and without checking for overflow. This changes SQL::Value to behave like SQLite for INTEGER types. In SQLite, the INTEGER type does not imply a size or signedness of the underlying type. Instead, SQLite determines on-the-fly what type is needed as values are created and updated. To do so, the SQL::Value variant can now hold an i64 or u64 integer. If a specific type is requested, invalid conversions are now explictly an error (e.g. converting a stored -1 to a u64 will fail). When binary mathematical operations are performed, we now try to coerce the RHS value to a type that works with the LHS value, failing the operation if that isn't possible. Any overflow or invalid operation (e.g. bitshifting a 64-bit value by more than 64 bytes) is an error.
2022-12-11 11:44:11 -05:00
EXPECT(row.row[1].to_int<i32>().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); });
LibSQL+SQLServer: Remove Core::EventReceiver parent from SQL::Database This relationship was only used to provide factory methods for the database.
2023-08-07 11:03:42 -04:00
auto database = MUST(SQL::Database::create(db_name));
Tests: Prefer TRY_OR_FAIL() and MUST() over EXPECT(!.is_error()) Note that in some cases (in particular SQL::Result and PDFErrorOr), there is no Formatter defined for the error type, hence TRY_OR_FAIL cannot work as-is. Furthermore, this commit leaves untouched the places where MUST could be replaced by TRY_OR_FAIL. Inspired by: https://github.com/SerenityOS/serenity/pull/18710#discussion_r1186892445
2023-05-07 20:14:06 +02:00
MUST(database->open());
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);
LibSQL: Support 64-bit integer values and handle overflow errors Currently, integers are stored in LibSQL as 32-bit signed integers, even if the provided type is unsigned. This resulted in a series of unchecked unsigned-to-signed conversions, and prevented storing 64-bit values. Further, mathematical operations were performed without similar checks, and without checking for overflow. This changes SQL::Value to behave like SQLite for INTEGER types. In SQLite, the INTEGER type does not imply a size or signedness of the underlying type. Instead, SQLite determines on-the-fly what type is needed as values are created and updated. To do so, the SQL::Value variant can now hold an i64 or u64 integer. If a specific type is requested, invalid conversions are now explictly an error (e.g. converting a stored -1 to a u64 will fail). When binary mathematical operations are performed, we now try to coerce the RHS value to a type that works with the LHS value, failing the operation if that isn't possible. Any overflow or invalid operation (e.g. bitshifting a 64-bit value by more than 64 bytes) is an error.
2022-12-11 11:44:11 -05:00
EXPECT(row.row[1].to_int<i32>().value() >= 42);
EXPECT(row.row[1].to_int<i32>().value() <= 46);
EXPECT(row.row[3].to_int<i32>().value() >= 40);
EXPECT(row.row[3].to_int<i32>().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); });
LibSQL+SQLServer: Remove Core::EventReceiver parent from SQL::Database This relationship was only used to provide factory methods for the database.
2023-08-07 11:03:42 -04:00
auto database = MUST(SQL::Database::create(db_name));
Tests: Prefer TRY_OR_FAIL() and MUST() over EXPECT(!.is_error()) Note that in some cases (in particular SQL::Result and PDFErrorOr), there is no Formatter defined for the error type, hence TRY_OR_FAIL cannot work as-is. Furthermore, this commit leaves untouched the places where MUST could be replaced by TRY_OR_FAIL. Inspired by: https://github.com/SerenityOS/serenity/pull/18710#discussion_r1186892445
2023-05-07 20:14:06 +02:00
MUST(database->open());
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);
LibSQL: Support 64-bit integer values and handle overflow errors Currently, integers are stored in LibSQL as 32-bit signed integers, even if the provided type is unsigned. This resulted in a series of unchecked unsigned-to-signed conversions, and prevented storing 64-bit values. Further, mathematical operations were performed without similar checks, and without checking for overflow. This changes SQL::Value to behave like SQLite for INTEGER types. In SQLite, the INTEGER type does not imply a size or signedness of the underlying type. Instead, SQLite determines on-the-fly what type is needed as values are created and updated. To do so, the SQL::Value variant can now hold an i64 or u64 integer. If a specific type is requested, invalid conversions are now explictly an error (e.g. converting a stored -1 to a u64 will fail). When binary mathematical operations are performed, we now try to coerce the RHS value to a type that works with the LHS value, failing the operation if that isn't possible. Any overflow or invalid operation (e.g. bitshifting a 64-bit value by more than 64 bytes) is an error.
2022-12-11 11:44:11 -05:00
EXPECT_EQ(result[0].row[0].to_int<i32>(), 42);
Everywhere: Rename {Deprecated => Byte}String This commit un-deprecates DeprecatedString, and repurposes it as a byte string. As the null state has already been removed, there are no other particularly hairy blockers in repurposing this type as a byte string (what it _really_ is). This commit is auto-generated: $ xs=$(ack -l \bDeprecatedString\b\|deprecated_string AK Userland \ Meta Ports Ladybird Tests Kernel) $ perl -pie 's/\bDeprecatedString\b/ByteString/g; s/deprecated_string/byte_string/g' $xs $ clang-format --style=file -i \ $(git diff --name-only | grep \.cpp\|\.h) $ gn format $(git ls-files '*.gn' '*.gni')
2023-12-16 17:49:34 +03:30
EXPECT_EQ(result[0].row[1].to_byte_string(), "Test_1");
EXPECT_EQ(result[0].row[2].to_byte_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); });
LibSQL+SQLServer: Remove Core::EventReceiver parent from SQL::Database This relationship was only used to provide factory methods for the database.
2023-08-07 11:03:42 -04:00
auto database = MUST(SQL::Database::create(db_name));
Tests: Prefer TRY_OR_FAIL() and MUST() over EXPECT(!.is_error()) Note that in some cases (in particular SQL::Result and PDFErrorOr), there is no Formatter defined for the error type, hence TRY_OR_FAIL cannot work as-is. Furthermore, this commit leaves untouched the places where MUST could be replaced by TRY_OR_FAIL. Inspired by: https://github.com/SerenityOS/serenity/pull/18710#discussion_r1186892445
2023-05-07 20:14:06 +02:00
MUST(database->open());
LibSQL: Implement LIKE SQL expressions
2021-12-29 11:47:29 -03: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 ), "
"( '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); });
LibSQL+SQLServer: Remove Core::EventReceiver parent from SQL::Database This relationship was only used to provide factory methods for the database.
2023-08-07 11:03:42 -04:00
auto database = MUST(SQL::Database::create(db_name));
Tests: Prefer TRY_OR_FAIL() and MUST() over EXPECT(!.is_error()) Note that in some cases (in particular SQL::Result and PDFErrorOr), there is no Formatter defined for the error type, hence TRY_OR_FAIL cannot work as-is. Furthermore, this commit leaves untouched the places where MUST could be replaced by TRY_OR_FAIL. Inspired by: https://github.com/SerenityOS/serenity/pull/18710#discussion_r1186892445
2023-05-07 20:14:06 +02:00
MUST(database->open());
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
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);
LibSQL: Support 64-bit integer values and handle overflow errors Currently, integers are stored in LibSQL as 32-bit signed integers, even if the provided type is unsigned. This resulted in a series of unchecked unsigned-to-signed conversions, and prevented storing 64-bit values. Further, mathematical operations were performed without similar checks, and without checking for overflow. This changes SQL::Value to behave like SQLite for INTEGER types. In SQLite, the INTEGER type does not imply a size or signedness of the underlying type. Instead, SQLite determines on-the-fly what type is needed as values are created and updated. To do so, the SQL::Value variant can now hold an i64 or u64 integer. If a specific type is requested, invalid conversions are now explictly an error (e.g. converting a stored -1 to a u64 will fail). When binary mathematical operations are performed, we now try to coerce the RHS value to a type that works with the LHS value, failing the operation if that isn't possible. Any overflow or invalid operation (e.g. bitshifting a 64-bit value by more than 64 bytes) is an error.
2022-12-11 11:44:11 -05:00
EXPECT_EQ(result[0].row[1].to_int<i32>(), 40);
EXPECT_EQ(result[1].row[1].to_int<i32>(), 41);
EXPECT_EQ(result[2].row[1].to_int<i32>(), 42);
EXPECT_EQ(result[3].row[1].to_int<i32>(), 44);
EXPECT_EQ(result[4].row[1].to_int<i32>(), 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);
Everywhere: Rename {Deprecated => Byte}String This commit un-deprecates DeprecatedString, and repurposes it as a byte string. As the null state has already been removed, there are no other particularly hairy blockers in repurposing this type as a byte string (what it _really_ is). This commit is auto-generated: $ xs=$(ack -l \bDeprecatedString\b\|deprecated_string AK Userland \ Meta Ports Ladybird Tests Kernel) $ perl -pie 's/\bDeprecatedString\b/ByteString/g; s/deprecated_string/byte_string/g' $xs $ clang-format --style=file -i \ $(git diff --name-only | grep \.cpp\|\.h) $ gn format $(git ls-files '*.gn' '*.gni')
2023-12-16 17:49:34 +03:30
EXPECT_EQ(result[0].row[0].to_byte_string(), "Test_1");
EXPECT_EQ(result[1].row[0].to_byte_string(), "Test_2");
EXPECT_EQ(result[2].row[0].to_byte_string(), "Test_3");
EXPECT_EQ(result[3].row[0].to_byte_string(), "Test_4");
EXPECT_EQ(result[4].row[0].to_byte_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); });
LibSQL+SQLServer: Remove Core::EventReceiver parent from SQL::Database This relationship was only used to provide factory methods for the database.
2023-08-07 11:03:42 -04:00
auto database = MUST(SQL::Database::create(db_name));
Tests: Prefer TRY_OR_FAIL() and MUST() over EXPECT(!.is_error()) Note that in some cases (in particular SQL::Result and PDFErrorOr), there is no Formatter defined for the error type, hence TRY_OR_FAIL cannot work as-is. Furthermore, this commit leaves untouched the places where MUST could be replaced by TRY_OR_FAIL. Inspired by: https://github.com/SerenityOS/serenity/pull/18710#discussion_r1186892445
2023-05-07 20:14:06 +02:00
MUST(database->open());
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
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); });
LibSQL+SQLServer: Remove Core::EventReceiver parent from SQL::Database This relationship was only used to provide factory methods for the database.
2023-08-07 11:03:42 -04:00
auto database = MUST(SQL::Database::create(db_name));
Tests: Prefer TRY_OR_FAIL() and MUST() over EXPECT(!.is_error()) Note that in some cases (in particular SQL::Result and PDFErrorOr), there is no Formatter defined for the error type, hence TRY_OR_FAIL cannot work as-is. Furthermore, this commit leaves untouched the places where MUST could be replaced by TRY_OR_FAIL. Inspired by: https://github.com/SerenityOS/serenity/pull/18710#discussion_r1186892445
2023-05-07 20:14:06 +02:00
MUST(database->open());
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
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); });
LibSQL+SQLServer: Remove Core::EventReceiver parent from SQL::Database This relationship was only used to provide factory methods for the database.
2023-08-07 11:03:42 -04:00
auto database = MUST(SQL::Database::create(db_name));
Tests: Prefer TRY_OR_FAIL() and MUST() over EXPECT(!.is_error()) Note that in some cases (in particular SQL::Result and PDFErrorOr), there is no Formatter defined for the error type, hence TRY_OR_FAIL cannot work as-is. Furthermore, this commit leaves untouched the places where MUST could be replaced by TRY_OR_FAIL. Inspired by: https://github.com/SerenityOS/serenity/pull/18710#discussion_r1186892445
2023-05-07 20:14:06 +02:00
MUST(database->open());
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
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);
Everywhere: Rename {Deprecated => Byte}String This commit un-deprecates DeprecatedString, and repurposes it as a byte string. As the null state has already been removed, there are no other particularly hairy blockers in repurposing this type as a byte string (what it _really_ is). This commit is auto-generated: $ xs=$(ack -l \bDeprecatedString\b\|deprecated_string AK Userland \ Meta Ports Ladybird Tests Kernel) $ perl -pie 's/\bDeprecatedString\b/ByteString/g; s/deprecated_string/byte_string/g' $xs $ clang-format --style=file -i \ $(git diff --name-only | grep \.cpp\|\.h) $ gn format $(git ls-files '*.gn' '*.gni')
2023-12-16 17:49:34 +03:30
EXPECT_EQ(result[0].row[0].to_byte_string(), "Test_1");
LibSQL: Support 64-bit integer values and handle overflow errors Currently, integers are stored in LibSQL as 32-bit signed integers, even if the provided type is unsigned. This resulted in a series of unchecked unsigned-to-signed conversions, and prevented storing 64-bit values. Further, mathematical operations were performed without similar checks, and without checking for overflow. This changes SQL::Value to behave like SQLite for INTEGER types. In SQLite, the INTEGER type does not imply a size or signedness of the underlying type. Instead, SQLite determines on-the-fly what type is needed as values are created and updated. To do so, the SQL::Value variant can now hold an i64 or u64 integer. If a specific type is requested, invalid conversions are now explictly an error (e.g. converting a stored -1 to a u64 will fail). When binary mathematical operations are performed, we now try to coerce the RHS value to a type that works with the LHS value, failing the operation if that isn't possible. Any overflow or invalid operation (e.g. bitshifting a 64-bit value by more than 64 bytes) is an error.
2022-12-11 11:44:11 -05:00
EXPECT_EQ(result[0].row[1].to_int<i32>(), 47);
Everywhere: Rename {Deprecated => Byte}String This commit un-deprecates DeprecatedString, and repurposes it as a byte string. As the null state has already been removed, there are no other particularly hairy blockers in repurposing this type as a byte string (what it _really_ is). This commit is auto-generated: $ xs=$(ack -l \bDeprecatedString\b\|deprecated_string AK Userland \ Meta Ports Ladybird Tests Kernel) $ perl -pie 's/\bDeprecatedString\b/ByteString/g; s/deprecated_string/byte_string/g' $xs $ clang-format --style=file -i \ $(git diff --name-only | grep \.cpp\|\.h) $ gn format $(git ls-files '*.gn' '*.gni')
2023-12-16 17:49:34 +03:30
EXPECT_EQ(result[1].row[0].to_byte_string(), "Test_2");
LibSQL: Support 64-bit integer values and handle overflow errors Currently, integers are stored in LibSQL as 32-bit signed integers, even if the provided type is unsigned. This resulted in a series of unchecked unsigned-to-signed conversions, and prevented storing 64-bit values. Further, mathematical operations were performed without similar checks, and without checking for overflow. This changes SQL::Value to behave like SQLite for INTEGER types. In SQLite, the INTEGER type does not imply a size or signedness of the underlying type. Instead, SQLite determines on-the-fly what type is needed as values are created and updated. To do so, the SQL::Value variant can now hold an i64 or u64 integer. If a specific type is requested, invalid conversions are now explictly an error (e.g. converting a stored -1 to a u64 will fail). When binary mathematical operations are performed, we now try to coerce the RHS value to a type that works with the LHS value, failing the operation if that isn't possible. Any overflow or invalid operation (e.g. bitshifting a 64-bit value by more than 64 bytes) is an error.
2022-12-11 11:44:11 -05:00
EXPECT_EQ(result[1].row[1].to_int<i32>(), 40);
Everywhere: Rename {Deprecated => Byte}String This commit un-deprecates DeprecatedString, and repurposes it as a byte string. As the null state has already been removed, there are no other particularly hairy blockers in repurposing this type as a byte string (what it _really_ is). This commit is auto-generated: $ xs=$(ack -l \bDeprecatedString\b\|deprecated_string AK Userland \ Meta Ports Ladybird Tests Kernel) $ perl -pie 's/\bDeprecatedString\b/ByteString/g; s/deprecated_string/byte_string/g' $xs $ clang-format --style=file -i \ $(git diff --name-only | grep \.cpp\|\.h) $ gn format $(git ls-files '*.gn' '*.gni')
2023-12-16 17:49:34 +03:30
EXPECT_EQ(result[2].row[0].to_byte_string(), "Test_2");
LibSQL: Support 64-bit integer values and handle overflow errors Currently, integers are stored in LibSQL as 32-bit signed integers, even if the provided type is unsigned. This resulted in a series of unchecked unsigned-to-signed conversions, and prevented storing 64-bit values. Further, mathematical operations were performed without similar checks, and without checking for overflow. This changes SQL::Value to behave like SQLite for INTEGER types. In SQLite, the INTEGER type does not imply a size or signedness of the underlying type. Instead, SQLite determines on-the-fly what type is needed as values are created and updated. To do so, the SQL::Value variant can now hold an i64 or u64 integer. If a specific type is requested, invalid conversions are now explictly an error (e.g. converting a stored -1 to a u64 will fail). When binary mathematical operations are performed, we now try to coerce the RHS value to a type that works with the LHS value, failing the operation if that isn't possible. Any overflow or invalid operation (e.g. bitshifting a 64-bit value by more than 64 bytes) is an error.
2022-12-11 11:44:11 -05:00
EXPECT_EQ(result[2].row[1].to_int<i32>(), 42);
Everywhere: Rename {Deprecated => Byte}String This commit un-deprecates DeprecatedString, and repurposes it as a byte string. As the null state has already been removed, there are no other particularly hairy blockers in repurposing this type as a byte string (what it _really_ is). This commit is auto-generated: $ xs=$(ack -l \bDeprecatedString\b\|deprecated_string AK Userland \ Meta Ports Ladybird Tests Kernel) $ perl -pie 's/\bDeprecatedString\b/ByteString/g; s/deprecated_string/byte_string/g' $xs $ clang-format --style=file -i \ $(git diff --name-only | grep \.cpp\|\.h) $ gn format $(git ls-files '*.gn' '*.gni')
2023-12-16 17:49:34 +03:30
EXPECT_EQ(result[3].row[0].to_byte_string(), "Test_4");
LibSQL: Support 64-bit integer values and handle overflow errors Currently, integers are stored in LibSQL as 32-bit signed integers, even if the provided type is unsigned. This resulted in a series of unchecked unsigned-to-signed conversions, and prevented storing 64-bit values. Further, mathematical operations were performed without similar checks, and without checking for overflow. This changes SQL::Value to behave like SQLite for INTEGER types. In SQLite, the INTEGER type does not imply a size or signedness of the underlying type. Instead, SQLite determines on-the-fly what type is needed as values are created and updated. To do so, the SQL::Value variant can now hold an i64 or u64 integer. If a specific type is requested, invalid conversions are now explictly an error (e.g. converting a stored -1 to a u64 will fail). When binary mathematical operations are performed, we now try to coerce the RHS value to a type that works with the LHS value, failing the operation if that isn't possible. Any overflow or invalid operation (e.g. bitshifting a 64-bit value by more than 64 bytes) is an error.
2022-12-11 11:44:11 -05:00
EXPECT_EQ(result[3].row[1].to_int<i32>(), 41);
Everywhere: Rename {Deprecated => Byte}String This commit un-deprecates DeprecatedString, and repurposes it as a byte string. As the null state has already been removed, there are no other particularly hairy blockers in repurposing this type as a byte string (what it _really_ is). This commit is auto-generated: $ xs=$(ack -l \bDeprecatedString\b\|deprecated_string AK Userland \ Meta Ports Ladybird Tests Kernel) $ perl -pie 's/\bDeprecatedString\b/ByteString/g; s/deprecated_string/byte_string/g' $xs $ clang-format --style=file -i \ $(git diff --name-only | grep \.cpp\|\.h) $ gn format $(git ls-files '*.gn' '*.gni')
2023-12-16 17:49:34 +03:30
EXPECT_EQ(result[4].row[0].to_byte_string(), "Test_5");
LibSQL: Support 64-bit integer values and handle overflow errors Currently, integers are stored in LibSQL as 32-bit signed integers, even if the provided type is unsigned. This resulted in a series of unchecked unsigned-to-signed conversions, and prevented storing 64-bit values. Further, mathematical operations were performed without similar checks, and without checking for overflow. This changes SQL::Value to behave like SQLite for INTEGER types. In SQLite, the INTEGER type does not imply a size or signedness of the underlying type. Instead, SQLite determines on-the-fly what type is needed as values are created and updated. To do so, the SQL::Value variant can now hold an i64 or u64 integer. If a specific type is requested, invalid conversions are now explictly an error (e.g. converting a stored -1 to a u64 will fail). When binary mathematical operations are performed, we now try to coerce the RHS value to a type that works with the LHS value, failing the operation if that isn't possible. Any overflow or invalid operation (e.g. bitshifting a 64-bit value by more than 64 bytes) is an error.
2022-12-11 11:44:11 -05:00
EXPECT_EQ(result[4].row[1].to_int<i32>(), 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); });
LibSQL+SQLServer: Remove Core::EventReceiver parent from SQL::Database This relationship was only used to provide factory methods for the database.
2023-08-07 11:03:42 -04:00
auto database = MUST(SQL::Database::create(db_name));
Tests: Prefer TRY_OR_FAIL() and MUST() over EXPECT(!.is_error()) Note that in some cases (in particular SQL::Result and PDFErrorOr), there is no Formatter defined for the error type, hence TRY_OR_FAIL cannot work as-is. Furthermore, this commit leaves untouched the places where MUST could be replaced by TRY_OR_FAIL. Inspired by: https://github.com/SerenityOS/serenity/pull/18710#discussion_r1186892445
2023-05-07 20:14:06 +02:00
MUST(database->open());
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
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);
Everywhere: Rename {Deprecated => Byte}String This commit un-deprecates DeprecatedString, and repurposes it as a byte string. As the null state has already been removed, there are no other particularly hairy blockers in repurposing this type as a byte string (what it _really_ is). This commit is auto-generated: $ xs=$(ack -l \bDeprecatedString\b\|deprecated_string AK Userland \ Meta Ports Ladybird Tests Kernel) $ perl -pie 's/\bDeprecatedString\b/ByteString/g; s/deprecated_string/byte_string/g' $xs $ clang-format --style=file -i \ $(git diff --name-only | grep \.cpp\|\.h) $ gn format $(git ls-files '*.gn' '*.gni')
2023-12-16 17:49:34 +03:30
EXPECT_EQ(result[0].row[0].to_byte_string(), "Test_3");
EXPECT_EQ(result[1].row[0].to_byte_string(), "Test_4");
EXPECT_EQ(result[2].row[0].to_byte_string(), "Test_2");
EXPECT_EQ(result[3].row[0].to_byte_string(), "Test_5");
EXPECT_EQ(result[4].row[0].to_byte_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); });
LibSQL+SQLServer: Remove Core::EventReceiver parent from SQL::Database This relationship was only used to provide factory methods for the database.
2023-08-07 11:03:42 -04:00
auto database = MUST(SQL::Database::create(db_name));
Tests: Prefer TRY_OR_FAIL() and MUST() over EXPECT(!.is_error()) Note that in some cases (in particular SQL::Result and PDFErrorOr), there is no Formatter defined for the error type, hence TRY_OR_FAIL cannot work as-is. Furthermore, this commit leaves untouched the places where MUST could be replaced by TRY_OR_FAIL. Inspired by: https://github.com/SerenityOS/serenity/pull/18710#discussion_r1186892445
2023-05-07 20:14:06 +02:00
MUST(database->open());
LibSQL: Introduce SELECT ... LIMIT xxx OFFSET yyy What it says on the tin.
2022-01-12 11:41:58 -05:00
create_table(database);
for (auto count = 0; count < 100; count++) {
auto result = execute(database,
Everywhere: Rename {Deprecated => Byte}String This commit un-deprecates DeprecatedString, and repurposes it as a byte string. As the null state has already been removed, there are no other particularly hairy blockers in repurposing this type as a byte string (what it _really_ is). This commit is auto-generated: $ xs=$(ack -l \bDeprecatedString\b\|deprecated_string AK Userland \ Meta Ports Ladybird Tests Kernel) $ perl -pie 's/\bDeprecatedString\b/ByteString/g; s/deprecated_string/byte_string/g' $xs $ clang-format --style=file -i \ $(git diff --name-only | grep \.cpp\|\.h) $ gn format $(git ls-files '*.gn' '*.gni')
2023-12-16 17:49:34 +03:30
ByteString::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); });
LibSQL+SQLServer: Remove Core::EventReceiver parent from SQL::Database This relationship was only used to provide factory methods for the database.
2023-08-07 11:03:42 -04:00
auto database = MUST(SQL::Database::create(db_name));
Tests: Prefer TRY_OR_FAIL() and MUST() over EXPECT(!.is_error()) Note that in some cases (in particular SQL::Result and PDFErrorOr), there is no Formatter defined for the error type, hence TRY_OR_FAIL cannot work as-is. Furthermore, this commit leaves untouched the places where MUST could be replaced by TRY_OR_FAIL. Inspired by: https://github.com/SerenityOS/serenity/pull/18710#discussion_r1186892445
2023-05-07 20:14:06 +02:00
MUST(database->open());
LibSQL: Introduce SELECT ... LIMIT xxx OFFSET yyy What it says on the tin.
2022-01-12 11:41:58 -05:00
create_table(database);
for (auto count = 0; count < 100; count++) {
auto result = execute(database,
Everywhere: Rename {Deprecated => Byte}String This commit un-deprecates DeprecatedString, and repurposes it as a byte string. As the null state has already been removed, there are no other particularly hairy blockers in repurposing this type as a byte string (what it _really_ is). This commit is auto-generated: $ xs=$(ack -l \bDeprecatedString\b\|deprecated_string AK Userland \ Meta Ports Ladybird Tests Kernel) $ perl -pie 's/\bDeprecatedString\b/ByteString/g; s/deprecated_string/byte_string/g' $xs $ clang-format --style=file -i \ $(git diff --name-only | grep \.cpp\|\.h) $ gn format $(git ls-files '*.gn' '*.gni')
2023-12-16 17:49:34 +03:30
ByteString::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); });
LibSQL+SQLServer: Remove Core::EventReceiver parent from SQL::Database This relationship was only used to provide factory methods for the database.
2023-08-07 11:03:42 -04:00
auto database = MUST(SQL::Database::create(db_name));
Tests: Prefer TRY_OR_FAIL() and MUST() over EXPECT(!.is_error()) Note that in some cases (in particular SQL::Result and PDFErrorOr), there is no Formatter defined for the error type, hence TRY_OR_FAIL cannot work as-is. Furthermore, this commit leaves untouched the places where MUST could be replaced by TRY_OR_FAIL. Inspired by: https://github.com/SerenityOS/serenity/pull/18710#discussion_r1186892445
2023-05-07 20:14:06 +02:00
MUST(database->open());
LibSQL: Introduce SELECT ... LIMIT xxx OFFSET yyy What it says on the tin.
2022-01-12 11:41:58 -05:00
create_table(database);
for (auto count = 0; count < 100; count++) {
auto result = execute(database,
Everywhere: Rename {Deprecated => Byte}String This commit un-deprecates DeprecatedString, and repurposes it as a byte string. As the null state has already been removed, there are no other particularly hairy blockers in repurposing this type as a byte string (what it _really_ is). This commit is auto-generated: $ xs=$(ack -l \bDeprecatedString\b\|deprecated_string AK Userland \ Meta Ports Ladybird Tests Kernel) $ perl -pie 's/\bDeprecatedString\b/ByteString/g; s/deprecated_string/byte_string/g' $xs $ clang-format --style=file -i \ $(git diff --name-only | grep \.cpp\|\.h) $ gn format $(git ls-files '*.gn' '*.gni')
2023-12-16 17:49:34 +03:30
ByteString::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);
LibSQL: Support 64-bit integer values and handle overflow errors Currently, integers are stored in LibSQL as 32-bit signed integers, even if the provided type is unsigned. This resulted in a series of unchecked unsigned-to-signed conversions, and prevented storing 64-bit values. Further, mathematical operations were performed without similar checks, and without checking for overflow. This changes SQL::Value to behave like SQLite for INTEGER types. In SQLite, the INTEGER type does not imply a size or signedness of the underlying type. Instead, SQLite determines on-the-fly what type is needed as values are created and updated. To do so, the SQL::Value variant can now hold an i64 or u64 integer. If a specific type is requested, invalid conversions are now explictly an error (e.g. converting a stored -1 to a u64 will fail). When binary mathematical operations are performed, we now try to coerce the RHS value to a type that works with the LHS value, failing the operation if that isn't possible. Any overflow or invalid operation (e.g. bitshifting a 64-bit value by more than 64 bytes) is an error.
2022-12-11 11:44:11 -05:00
EXPECT_EQ(result[0].row[1].to_int<i32>(), 10);
EXPECT_EQ(result[1].row[1].to_int<i32>(), 11);
EXPECT_EQ(result[2].row[1].to_int<i32>(), 12);
EXPECT_EQ(result[3].row[1].to_int<i32>(), 13);
EXPECT_EQ(result[4].row[1].to_int<i32>(), 14);
EXPECT_EQ(result[5].row[1].to_int<i32>(), 15);
EXPECT_EQ(result[6].row[1].to_int<i32>(), 16);
EXPECT_EQ(result[7].row[1].to_int<i32>(), 17);
EXPECT_EQ(result[8].row[1].to_int<i32>(), 18);
EXPECT_EQ(result[9].row[1].to_int<i32>(), 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); });
LibSQL+SQLServer: Remove Core::EventReceiver parent from SQL::Database This relationship was only used to provide factory methods for the database.
2023-08-07 11:03:42 -04:00
auto database = MUST(SQL::Database::create(db_name));
Tests: Prefer TRY_OR_FAIL() and MUST() over EXPECT(!.is_error()) Note that in some cases (in particular SQL::Result and PDFErrorOr), there is no Formatter defined for the error type, hence TRY_OR_FAIL cannot work as-is. Furthermore, this commit leaves untouched the places where MUST could be replaced by TRY_OR_FAIL. Inspired by: https://github.com/SerenityOS/serenity/pull/18710#discussion_r1186892445
2023-05-07 20:14:06 +02:00
MUST(database->open());
LibSQL: Introduce SELECT ... LIMIT xxx OFFSET yyy What it says on the tin.
2022-01-12 11:41:58 -05:00
create_table(database);
for (auto count = 0; count < 100; count++) {
auto result = execute(database,
Everywhere: Rename {Deprecated => Byte}String This commit un-deprecates DeprecatedString, and repurposes it as a byte string. As the null state has already been removed, there are no other particularly hairy blockers in repurposing this type as a byte string (what it _really_ is). This commit is auto-generated: $ xs=$(ack -l \bDeprecatedString\b\|deprecated_string AK Userland \ Meta Ports Ladybird Tests Kernel) $ perl -pie 's/\bDeprecatedString\b/ByteString/g; s/deprecated_string/byte_string/g' $xs $ clang-format --style=file -i \ $(git diff --name-only | grep \.cpp\|\.h) $ gn format $(git ls-files '*.gn' '*.gni')
2023-12-16 17:49:34 +03:30
ByteString::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); });
LibSQL+SQLServer: Remove Core::EventReceiver parent from SQL::Database This relationship was only used to provide factory methods for the database.
2023-08-07 11:03:42 -04:00
auto database = MUST(SQL::Database::create(db_name));
Tests: Prefer TRY_OR_FAIL() and MUST() over EXPECT(!.is_error()) Note that in some cases (in particular SQL::Result and PDFErrorOr), there is no Formatter defined for the error type, hence TRY_OR_FAIL cannot work as-is. Furthermore, this commit leaves untouched the places where MUST could be replaced by TRY_OR_FAIL. Inspired by: https://github.com/SerenityOS/serenity/pull/18710#discussion_r1186892445
2023-05-07 20:14:06 +02:00
MUST(database->open());
LibSQL: Introduce SELECT ... LIMIT xxx OFFSET yyy What it says on the tin.
2022-01-12 11:41:58 -05:00
create_table(database);
for (auto count = 0; count < 100; count++) {
auto result = execute(database,
Everywhere: Rename {Deprecated => Byte}String This commit un-deprecates DeprecatedString, and repurposes it as a byte string. As the null state has already been removed, there are no other particularly hairy blockers in repurposing this type as a byte string (what it _really_ is). This commit is auto-generated: $ xs=$(ack -l \bDeprecatedString\b\|deprecated_string AK Userland \ Meta Ports Ladybird Tests Kernel) $ perl -pie 's/\bDeprecatedString\b/ByteString/g; s/deprecated_string/byte_string/g' $xs $ clang-format --style=file -i \ $(git diff --name-only | grep \.cpp\|\.h) $ gn format $(git ls-files '*.gn' '*.gni')
2023-12-16 17:49:34 +03:30
ByteString::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); });
LibSQL+SQLServer: Remove Core::EventReceiver parent from SQL::Database This relationship was only used to provide factory methods for the database.
2023-08-07 11:03:42 -04:00
auto database = MUST(SQL::Database::create(db_name));
Tests: Prefer TRY_OR_FAIL() and MUST() over EXPECT(!.is_error()) Note that in some cases (in particular SQL::Result and PDFErrorOr), there is no Formatter defined for the error type, hence TRY_OR_FAIL cannot work as-is. Furthermore, this commit leaves untouched the places where MUST could be replaced by TRY_OR_FAIL. Inspired by: https://github.com/SerenityOS/serenity/pull/18710#discussion_r1186892445
2023-05-07 20:14:06 +02:00
MUST(database->open());
LibSQL: Implement DESCRIBE TABLE tests
2021-09-19 21:35:16 +02:00
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);
Everywhere: Rename {Deprecated => Byte}String This commit un-deprecates DeprecatedString, and repurposes it as a byte string. As the null state has already been removed, there are no other particularly hairy blockers in repurposing this type as a byte string (what it _really_ is). This commit is auto-generated: $ xs=$(ack -l \bDeprecatedString\b\|deprecated_string AK Userland \ Meta Ports Ladybird Tests Kernel) $ perl -pie 's/\bDeprecatedString\b/ByteString/g; s/deprecated_string/byte_string/g' $xs $ clang-format --style=file -i \ $(git diff --name-only | grep \.cpp\|\.h) $ gn format $(git ls-files '*.gn' '*.gni')
2023-12-16 17:49:34 +03:30
EXPECT_EQ(result[0].row[0].to_byte_string(), "TEXTCOLUMN");
EXPECT_EQ(result[0].row[1].to_byte_string(), "text");
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
Everywhere: Rename {Deprecated => Byte}String This commit un-deprecates DeprecatedString, and repurposes it as a byte string. As the null state has already been removed, there are no other particularly hairy blockers in repurposing this type as a byte string (what it _really_ is). This commit is auto-generated: $ xs=$(ack -l \bDeprecatedString\b\|deprecated_string AK Userland \ Meta Ports Ladybird Tests Kernel) $ perl -pie 's/\bDeprecatedString\b/ByteString/g; s/deprecated_string/byte_string/g' $xs $ clang-format --style=file -i \ $(git diff --name-only | grep \.cpp\|\.h) $ gn format $(git ls-files '*.gn' '*.gni')
2023-12-16 17:49:34 +03:30
EXPECT_EQ(result[1].row[0].to_byte_string(), "INTCOLUMN");
EXPECT_EQ(result[1].row[1].to_byte_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); });
LibSQL+SQLServer: Remove Core::EventReceiver parent from SQL::Database This relationship was only used to provide factory methods for the database.
2023-08-07 11:03:42 -04:00
auto database = MUST(SQL::Database::create(db_name));
Tests: Prefer TRY_OR_FAIL() and MUST() over EXPECT(!.is_error()) Note that in some cases (in particular SQL::Result and PDFErrorOr), there is no Formatter defined for the error type, hence TRY_OR_FAIL cannot work as-is. Furthermore, this commit leaves untouched the places where MUST could be replaced by TRY_OR_FAIL. Inspired by: https://github.com/SerenityOS/serenity/pull/18710#discussion_r1186892445
2023-05-07 20:14:06 +02:00
MUST(database->open());
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
create_table(database);
for (auto count = 0; count < 10; ++count) {
Everywhere: Rename {Deprecated => Byte}String This commit un-deprecates DeprecatedString, and repurposes it as a byte string. As the null state has already been removed, there are no other particularly hairy blockers in repurposing this type as a byte string (what it _really_ is). This commit is auto-generated: $ xs=$(ack -l \bDeprecatedString\b\|deprecated_string AK Userland \ Meta Ports Ladybird Tests Kernel) $ perl -pie 's/\bDeprecatedString\b/ByteString/g; s/deprecated_string/byte_string/g' $xs $ clang-format --style=file -i \ $(git diff --name-only | grep \.cpp\|\.h) $ gn format $(git ls-files '*.gn' '*.gni')
2023-12-16 17:49:34 +03:30
auto result = execute(database, ByteString::formatted("INSERT INTO TestSchema.TestTable VALUES ( 'T{}', {} );", count, count));
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
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);
LibSQL: Support 64-bit integer values and handle overflow errors Currently, integers are stored in LibSQL as 32-bit signed integers, even if the provided type is unsigned. This resulted in a series of unchecked unsigned-to-signed conversions, and prevented storing 64-bit values. Further, mathematical operations were performed without similar checks, and without checking for overflow. This changes SQL::Value to behave like SQLite for INTEGER types. In SQLite, the INTEGER type does not imply a size or signedness of the underlying type. Instead, SQLite determines on-the-fly what type is needed as values are created and updated. To do so, the SQL::Value variant can now hold an i64 or u64 integer. If a specific type is requested, invalid conversions are now explictly an error (e.g. converting a stored -1 to a u64 will fail). When binary mathematical operations are performed, we now try to coerce the RHS value to a type that works with the LHS value, failing the operation if that isn't possible. Any overflow or invalid operation (e.g. bitshifting a 64-bit value by more than 64 bytes) is an error.
2022-12-11 11:44:11 -05:00
auto result_column = result_row[0].to_int<i32>();
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
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); });
LibSQL+SQLServer: Remove Core::EventReceiver parent from SQL::Database This relationship was only used to provide factory methods for the database.
2023-08-07 11:03:42 -04:00
auto database = MUST(SQL::Database::create(db_name));
Tests: Prefer TRY_OR_FAIL() and MUST() over EXPECT(!.is_error()) Note that in some cases (in particular SQL::Result and PDFErrorOr), there is no Formatter defined for the error type, hence TRY_OR_FAIL cannot work as-is. Furthermore, this commit leaves untouched the places where MUST could be replaced by TRY_OR_FAIL. Inspired by: https://github.com/SerenityOS/serenity/pull/18710#discussion_r1186892445
2023-05-07 20:14:06 +02:00
MUST(database->open());
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
create_table(database);
for (auto count = 0; count < 10; ++count) {
Everywhere: Rename {Deprecated => Byte}String This commit un-deprecates DeprecatedString, and repurposes it as a byte string. As the null state has already been removed, there are no other particularly hairy blockers in repurposing this type as a byte string (what it _really_ is). This commit is auto-generated: $ xs=$(ack -l \bDeprecatedString\b\|deprecated_string AK Userland \ Meta Ports Ladybird Tests Kernel) $ perl -pie 's/\bDeprecatedString\b/ByteString/g; s/deprecated_string/byte_string/g' $xs $ clang-format --style=file -i \ $(git diff --name-only | grep \.cpp\|\.h) $ gn format $(git ls-files '*.gn' '*.gni')
2023-12-16 17:49:34 +03:30
auto result = execute(database, ByteString::formatted("INSERT INTO TestSchema.TestTable VALUES ( 'T{}', {} );", count, count));
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
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);
Everywhere: Rename {Deprecated => Byte}String This commit un-deprecates DeprecatedString, and repurposes it as a byte string. As the null state has already been removed, there are no other particularly hairy blockers in repurposing this type as a byte string (what it _really_ is). This commit is auto-generated: $ xs=$(ack -l \bDeprecatedString\b\|deprecated_string AK Userland \ Meta Ports Ladybird Tests Kernel) $ perl -pie 's/\bDeprecatedString\b/ByteString/g; s/deprecated_string/byte_string/g' $xs $ clang-format --style=file -i \ $(git diff --name-only | grep \.cpp\|\.h) $ gn format $(git ls-files '*.gn' '*.gni')
2023-12-16 17:49:34 +03:30
auto message = ByteString::formatted("NumericOperatorTypeMismatch: Cannot apply '{}' operator to non-numeric operands", op);
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
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); });
{
LibSQL+SQLServer: Remove Core::EventReceiver parent from SQL::Database This relationship was only used to provide factory methods for the database.
2023-08-07 11:03:42 -04:00
auto database = MUST(SQL::Database::create(db_name));
Tests: Prefer TRY_OR_FAIL() and MUST() over EXPECT(!.is_error()) Note that in some cases (in particular SQL::Result and PDFErrorOr), there is no Formatter defined for the error type, hence TRY_OR_FAIL cannot work as-is. Furthermore, this commit leaves untouched the places where MUST could be replaced by TRY_OR_FAIL. Inspired by: https://github.com/SerenityOS/serenity/pull/18710#discussion_r1186892445
2023-05-07 20:14:06 +02:00
MUST(database->open());
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
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);
}
{
LibSQL+SQLServer: Remove Core::EventReceiver parent from SQL::Database This relationship was only used to provide factory methods for the database.
2023-08-07 11:03:42 -04:00
auto database = MUST(SQL::Database::create(db_name));
Tests: Prefer TRY_OR_FAIL() and MUST() over EXPECT(!.is_error()) Note that in some cases (in particular SQL::Result and PDFErrorOr), there is no Formatter defined for the error type, hence TRY_OR_FAIL cannot work as-is. Furthermore, this commit leaves untouched the places where MUST could be replaced by TRY_OR_FAIL. Inspired by: https://github.com/SerenityOS/serenity/pull/18710#discussion_r1186892445
2023-05-07 20:14:06 +02:00
MUST(database->open());
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
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); });
{
LibSQL+SQLServer: Remove Core::EventReceiver parent from SQL::Database This relationship was only used to provide factory methods for the database.
2023-08-07 11:03:42 -04:00
auto database = MUST(SQL::Database::create(db_name));
Tests: Prefer TRY_OR_FAIL() and MUST() over EXPECT(!.is_error()) Note that in some cases (in particular SQL::Result and PDFErrorOr), there is no Formatter defined for the error type, hence TRY_OR_FAIL cannot work as-is. Furthermore, this commit leaves untouched the places where MUST could be replaced by TRY_OR_FAIL. Inspired by: https://github.com/SerenityOS/serenity/pull/18710#discussion_r1186892445
2023-05-07 20:14:06 +02:00
MUST(database->open());
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
create_table(database);
for (auto count = 0; count < 10; ++count) {
Everywhere: Rename {Deprecated => Byte}String This commit un-deprecates DeprecatedString, and repurposes it as a byte string. As the null state has already been removed, there are no other particularly hairy blockers in repurposing this type as a byte string (what it _really_ is). This commit is auto-generated: $ xs=$(ack -l \bDeprecatedString\b\|deprecated_string AK Userland \ Meta Ports Ladybird Tests Kernel) $ perl -pie 's/\bDeprecatedString\b/ByteString/g; s/deprecated_string/byte_string/g' $xs $ clang-format --style=file -i \ $(git diff --name-only | grep \.cpp\|\.h) $ gn format $(git ls-files '*.gn' '*.gni')
2023-12-16 17:49:34 +03:30
auto result = execute(database, ByteString::formatted("INSERT INTO TestSchema.TestTable VALUES ( 'T{}', {} );", count, count));
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
EXPECT_EQ(result.size(), 1u);
}
auto result = execute(database, "SELECT * FROM TestSchema.TestTable;");
EXPECT_EQ(result.size(), 10u);
}
{
LibSQL+SQLServer: Remove Core::EventReceiver parent from SQL::Database This relationship was only used to provide factory methods for the database.
2023-08-07 11:03:42 -04:00
auto database = MUST(SQL::Database::create(db_name));
Tests: Prefer TRY_OR_FAIL() and MUST() over EXPECT(!.is_error()) Note that in some cases (in particular SQL::Result and PDFErrorOr), there is no Formatter defined for the error type, hence TRY_OR_FAIL cannot work as-is. Furthermore, this commit leaves untouched the places where MUST could be replaced by TRY_OR_FAIL. Inspired by: https://github.com/SerenityOS/serenity/pull/18710#discussion_r1186892445
2023-05-07 20:14:06 +02:00
MUST(database->open());
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
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);
}
{
LibSQL+SQLServer: Remove Core::EventReceiver parent from SQL::Database This relationship was only used to provide factory methods for the database.
2023-08-07 11:03:42 -04:00
auto database = MUST(SQL::Database::create(db_name));
Tests: Prefer TRY_OR_FAIL() and MUST() over EXPECT(!.is_error()) Note that in some cases (in particular SQL::Result and PDFErrorOr), there is no Formatter defined for the error type, hence TRY_OR_FAIL cannot work as-is. Furthermore, this commit leaves untouched the places where MUST could be replaced by TRY_OR_FAIL. Inspired by: https://github.com/SerenityOS/serenity/pull/18710#discussion_r1186892445
2023-05-07 20:14:06 +02:00
MUST(database->open());
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
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); });
{
LibSQL+SQLServer: Remove Core::EventReceiver parent from SQL::Database This relationship was only used to provide factory methods for the database.
2023-08-07 11:03:42 -04:00
auto database = MUST(SQL::Database::create(db_name));
Tests: Prefer TRY_OR_FAIL() and MUST() over EXPECT(!.is_error()) Note that in some cases (in particular SQL::Result and PDFErrorOr), there is no Formatter defined for the error type, hence TRY_OR_FAIL cannot work as-is. Furthermore, this commit leaves untouched the places where MUST could be replaced by TRY_OR_FAIL. Inspired by: https://github.com/SerenityOS/serenity/pull/18710#discussion_r1186892445
2023-05-07 20:14:06 +02:00
MUST(database->open());
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
create_table(database);
for (auto count = 0; count < 10; ++count) {
Everywhere: Rename {Deprecated => Byte}String This commit un-deprecates DeprecatedString, and repurposes it as a byte string. As the null state has already been removed, there are no other particularly hairy blockers in repurposing this type as a byte string (what it _really_ is). This commit is auto-generated: $ xs=$(ack -l \bDeprecatedString\b\|deprecated_string AK Userland \ Meta Ports Ladybird Tests Kernel) $ perl -pie 's/\bDeprecatedString\b/ByteString/g; s/deprecated_string/byte_string/g' $xs $ clang-format --style=file -i \ $(git diff --name-only | grep \.cpp\|\.h) $ gn format $(git ls-files '*.gn' '*.gni')
2023-12-16 17:49:34 +03:30
auto result = execute(database, ByteString::formatted("INSERT INTO TestSchema.TestTable VALUES ( 'T{}', {} );", count, count));
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
EXPECT_EQ(result.size(), 1u);
}
auto result = execute(database, "SELECT * FROM TestSchema.TestTable;");
EXPECT_EQ(result.size(), 10u);
}
{
LibSQL+SQLServer: Remove Core::EventReceiver parent from SQL::Database This relationship was only used to provide factory methods for the database.
2023-08-07 11:03:42 -04:00
auto database = MUST(SQL::Database::create(db_name));
Tests: Prefer TRY_OR_FAIL() and MUST() over EXPECT(!.is_error()) Note that in some cases (in particular SQL::Result and PDFErrorOr), there is no Formatter defined for the error type, hence TRY_OR_FAIL cannot work as-is. Furthermore, this commit leaves untouched the places where MUST could be replaced by TRY_OR_FAIL. Inspired by: https://github.com/SerenityOS/serenity/pull/18710#discussion_r1186892445
2023-05-07 20:14:06 +02:00
MUST(database->open());
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
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);
}
{
LibSQL+SQLServer: Remove Core::EventReceiver parent from SQL::Database This relationship was only used to provide factory methods for the database.
2023-08-07 11:03:42 -04:00
auto database = MUST(SQL::Database::create(db_name));
Tests: Prefer TRY_OR_FAIL() and MUST() over EXPECT(!.is_error()) Note that in some cases (in particular SQL::Result and PDFErrorOr), there is no Formatter defined for the error type, hence TRY_OR_FAIL cannot work as-is. Furthermore, this commit leaves untouched the places where MUST could be replaced by TRY_OR_FAIL. Inspired by: https://github.com/SerenityOS/serenity/pull/18710#discussion_r1186892445
2023-05-07 20:14:06 +02:00
MUST(database->open());
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
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); });
{
LibSQL+SQLServer: Remove Core::EventReceiver parent from SQL::Database This relationship was only used to provide factory methods for the database.
2023-08-07 11:03:42 -04:00
auto database = MUST(SQL::Database::create(db_name));
Tests: Prefer TRY_OR_FAIL() and MUST() over EXPECT(!.is_error()) Note that in some cases (in particular SQL::Result and PDFErrorOr), there is no Formatter defined for the error type, hence TRY_OR_FAIL cannot work as-is. Furthermore, this commit leaves untouched the places where MUST could be replaced by TRY_OR_FAIL. Inspired by: https://github.com/SerenityOS/serenity/pull/18710#discussion_r1186892445
2023-05-07 20:14:06 +02:00
MUST(database->open());
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
create_table(database);
for (auto count = 0; count < 10; ++count) {
Everywhere: Rename {Deprecated => Byte}String This commit un-deprecates DeprecatedString, and repurposes it as a byte string. As the null state has already been removed, there are no other particularly hairy blockers in repurposing this type as a byte string (what it _really_ is). This commit is auto-generated: $ xs=$(ack -l \bDeprecatedString\b\|deprecated_string AK Userland \ Meta Ports Ladybird Tests Kernel) $ perl -pie 's/\bDeprecatedString\b/ByteString/g; s/deprecated_string/byte_string/g' $xs $ clang-format --style=file -i \ $(git diff --name-only | grep \.cpp\|\.h) $ gn format $(git ls-files '*.gn' '*.gni')
2023-12-16 17:49:34 +03:30
auto result = execute(database, ByteString::formatted("INSERT INTO TestSchema.TestTable VALUES ( 'T{}', {} );", count, count));
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
EXPECT_EQ(result.size(), 1u);
}
auto result = execute(database, "SELECT * FROM TestSchema.TestTable;");
EXPECT_EQ(result.size(), 10u);
}
{
LibSQL+SQLServer: Remove Core::EventReceiver parent from SQL::Database This relationship was only used to provide factory methods for the database.
2023-08-07 11:03:42 -04:00
auto database = MUST(SQL::Database::create(db_name));
Tests: Prefer TRY_OR_FAIL() and MUST() over EXPECT(!.is_error()) Note that in some cases (in particular SQL::Result and PDFErrorOr), there is no Formatter defined for the error type, hence TRY_OR_FAIL cannot work as-is. Furthermore, this commit leaves untouched the places where MUST could be replaced by TRY_OR_FAIL. Inspired by: https://github.com/SerenityOS/serenity/pull/18710#discussion_r1186892445
2023-05-07 20:14:06 +02:00
MUST(database->open());
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
execute(database, "DELETE FROM TestSchema.TestTable;");
auto result = execute(database, "SELECT * FROM TestSchema.TestTable;");
EXPECT(result.is_empty());
}
{
LibSQL+SQLServer: Remove Core::EventReceiver parent from SQL::Database This relationship was only used to provide factory methods for the database.
2023-08-07 11:03:42 -04:00
auto database = MUST(SQL::Database::create(db_name));
Tests: Prefer TRY_OR_FAIL() and MUST() over EXPECT(!.is_error()) Note that in some cases (in particular SQL::Result and PDFErrorOr), there is no Formatter defined for the error type, hence TRY_OR_FAIL cannot work as-is. Furthermore, this commit leaves untouched the places where MUST could be replaced by TRY_OR_FAIL. Inspired by: https://github.com/SerenityOS/serenity/pull/18710#discussion_r1186892445
2023-05-07 20:14:06 +02:00
MUST(database->open());
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
auto result = execute(database, "SELECT * FROM TestSchema.TestTable;");
EXPECT(result.is_empty());
}
}
LibSQL: Partially implement the UPDATE command This implements enough to update rows filtered by a WHERE clause.
2022-12-05 07:55:21 -05:00
TEST_CASE(update_single_row)
{
ScopeGuard guard([]() { unlink(db_name); });
{
LibSQL+SQLServer: Remove Core::EventReceiver parent from SQL::Database This relationship was only used to provide factory methods for the database.
2023-08-07 11:03:42 -04:00
auto database = MUST(SQL::Database::create(db_name));
Tests: Prefer TRY_OR_FAIL() and MUST() over EXPECT(!.is_error()) Note that in some cases (in particular SQL::Result and PDFErrorOr), there is no Formatter defined for the error type, hence TRY_OR_FAIL cannot work as-is. Furthermore, this commit leaves untouched the places where MUST could be replaced by TRY_OR_FAIL. Inspired by: https://github.com/SerenityOS/serenity/pull/18710#discussion_r1186892445
2023-05-07 20:14:06 +02:00
MUST(database->open());
LibSQL: Partially implement the UPDATE command This implements enough to update rows filtered by a WHERE clause.
2022-12-05 07:55:21 -05:00
create_table(database);
for (auto count = 0; count < 10; ++count) {
Everywhere: Rename {Deprecated => Byte}String This commit un-deprecates DeprecatedString, and repurposes it as a byte string. As the null state has already been removed, there are no other particularly hairy blockers in repurposing this type as a byte string (what it _really_ is). This commit is auto-generated: $ xs=$(ack -l \bDeprecatedString\b\|deprecated_string AK Userland \ Meta Ports Ladybird Tests Kernel) $ perl -pie 's/\bDeprecatedString\b/ByteString/g; s/deprecated_string/byte_string/g' $xs $ clang-format --style=file -i \ $(git diff --name-only | grep \.cpp\|\.h) $ gn format $(git ls-files '*.gn' '*.gni')
2023-12-16 17:49:34 +03:30
auto result = execute(database, ByteString::formatted("INSERT INTO TestSchema.TestTable VALUES ( 'T{}', {} );", count, count));
LibSQL: Partially implement the UPDATE command This implements enough to update rows filtered by a WHERE clause.
2022-12-05 07:55:21 -05:00
EXPECT_EQ(result.size(), 1u);
}
execute(database, "UPDATE TestSchema.TestTable SET IntColumn=123456 WHERE (TextColumn = 'T3');");
auto result = execute(database, "SELECT IntColumn FROM TestSchema.TestTable ORDER BY IntColumn;");
EXPECT_EQ(result.size(), 10u);
for (auto i = 0u; i < 10; ++i) {
if (i < 3)
EXPECT_EQ(result[i].row[0], i);
else if (i < 9)
EXPECT_EQ(result[i].row[0], i + 1);
else
EXPECT_EQ(result[i].row[0], 123456);
}
}
{
LibSQL+SQLServer: Remove Core::EventReceiver parent from SQL::Database This relationship was only used to provide factory methods for the database.
2023-08-07 11:03:42 -04:00
auto database = MUST(SQL::Database::create(db_name));
Tests: Prefer TRY_OR_FAIL() and MUST() over EXPECT(!.is_error()) Note that in some cases (in particular SQL::Result and PDFErrorOr), there is no Formatter defined for the error type, hence TRY_OR_FAIL cannot work as-is. Furthermore, this commit leaves untouched the places where MUST could be replaced by TRY_OR_FAIL. Inspired by: https://github.com/SerenityOS/serenity/pull/18710#discussion_r1186892445
2023-05-07 20:14:06 +02:00
MUST(database->open());
LibSQL: Partially implement the UPDATE command This implements enough to update rows filtered by a WHERE clause.
2022-12-05 07:55:21 -05:00
auto result = execute(database, "SELECT IntColumn FROM TestSchema.TestTable ORDER BY IntColumn;");
EXPECT_EQ(result.size(), 10u);
for (auto i = 0u; i < 10; ++i) {
if (i < 3)
EXPECT_EQ(result[i].row[0], i);
else if (i < 9)
EXPECT_EQ(result[i].row[0], i + 1);
else
EXPECT_EQ(result[i].row[0], 123456);
}
}
}
TEST_CASE(update_multiple_rows)
{
ScopeGuard guard([]() { unlink(db_name); });
{
LibSQL+SQLServer: Remove Core::EventReceiver parent from SQL::Database This relationship was only used to provide factory methods for the database.
2023-08-07 11:03:42 -04:00
auto database = MUST(SQL::Database::create(db_name));
Tests: Prefer TRY_OR_FAIL() and MUST() over EXPECT(!.is_error()) Note that in some cases (in particular SQL::Result and PDFErrorOr), there is no Formatter defined for the error type, hence TRY_OR_FAIL cannot work as-is. Furthermore, this commit leaves untouched the places where MUST could be replaced by TRY_OR_FAIL. Inspired by: https://github.com/SerenityOS/serenity/pull/18710#discussion_r1186892445
2023-05-07 20:14:06 +02:00
MUST(database->open());
LibSQL: Partially implement the UPDATE command This implements enough to update rows filtered by a WHERE clause.
2022-12-05 07:55:21 -05:00
create_table(database);
for (auto count = 0; count < 10; ++count) {
Everywhere: Rename {Deprecated => Byte}String This commit un-deprecates DeprecatedString, and repurposes it as a byte string. As the null state has already been removed, there are no other particularly hairy blockers in repurposing this type as a byte string (what it _really_ is). This commit is auto-generated: $ xs=$(ack -l \bDeprecatedString\b\|deprecated_string AK Userland \ Meta Ports Ladybird Tests Kernel) $ perl -pie 's/\bDeprecatedString\b/ByteString/g; s/deprecated_string/byte_string/g' $xs $ clang-format --style=file -i \ $(git diff --name-only | grep \.cpp\|\.h) $ gn format $(git ls-files '*.gn' '*.gni')
2023-12-16 17:49:34 +03:30
auto result = execute(database, ByteString::formatted("INSERT INTO TestSchema.TestTable VALUES ( 'T{}', {} );", count, count));
LibSQL: Partially implement the UPDATE command This implements enough to update rows filtered by a WHERE clause.
2022-12-05 07:55:21 -05:00
EXPECT_EQ(result.size(), 1u);
}
execute(database, "UPDATE TestSchema.TestTable SET IntColumn=123456 WHERE (IntColumn > 4);");
auto result = execute(database, "SELECT IntColumn FROM TestSchema.TestTable ORDER BY IntColumn;");
EXPECT_EQ(result.size(), 10u);
for (auto i = 0u; i < 10; ++i) {
if (i < 5)
EXPECT_EQ(result[i].row[0], i);
else
EXPECT_EQ(result[i].row[0], 123456);
}
}
{
LibSQL+SQLServer: Remove Core::EventReceiver parent from SQL::Database This relationship was only used to provide factory methods for the database.
2023-08-07 11:03:42 -04:00
auto database = MUST(SQL::Database::create(db_name));
Tests: Prefer TRY_OR_FAIL() and MUST() over EXPECT(!.is_error()) Note that in some cases (in particular SQL::Result and PDFErrorOr), there is no Formatter defined for the error type, hence TRY_OR_FAIL cannot work as-is. Furthermore, this commit leaves untouched the places where MUST could be replaced by TRY_OR_FAIL. Inspired by: https://github.com/SerenityOS/serenity/pull/18710#discussion_r1186892445
2023-05-07 20:14:06 +02:00
MUST(database->open());
LibSQL: Partially implement the UPDATE command This implements enough to update rows filtered by a WHERE clause.
2022-12-05 07:55:21 -05:00
auto result = execute(database, "SELECT IntColumn FROM TestSchema.TestTable ORDER BY IntColumn;");
EXPECT_EQ(result.size(), 10u);
for (auto i = 0u; i < 10; ++i) {
if (i < 5)
EXPECT_EQ(result[i].row[0], i);
else
EXPECT_EQ(result[i].row[0], 123456);
}
}
}
TEST_CASE(update_all_rows)
{
ScopeGuard guard([]() { unlink(db_name); });
{
LibSQL+SQLServer: Remove Core::EventReceiver parent from SQL::Database This relationship was only used to provide factory methods for the database.
2023-08-07 11:03:42 -04:00
auto database = MUST(SQL::Database::create(db_name));
Tests: Prefer TRY_OR_FAIL() and MUST() over EXPECT(!.is_error()) Note that in some cases (in particular SQL::Result and PDFErrorOr), there is no Formatter defined for the error type, hence TRY_OR_FAIL cannot work as-is. Furthermore, this commit leaves untouched the places where MUST could be replaced by TRY_OR_FAIL. Inspired by: https://github.com/SerenityOS/serenity/pull/18710#discussion_r1186892445
2023-05-07 20:14:06 +02:00
MUST(database->open());
LibSQL: Partially implement the UPDATE command This implements enough to update rows filtered by a WHERE clause.
2022-12-05 07:55:21 -05:00
create_table(database);
for (auto count = 0; count < 10; ++count) {
Everywhere: Rename {Deprecated => Byte}String This commit un-deprecates DeprecatedString, and repurposes it as a byte string. As the null state has already been removed, there are no other particularly hairy blockers in repurposing this type as a byte string (what it _really_ is). This commit is auto-generated: $ xs=$(ack -l \bDeprecatedString\b\|deprecated_string AK Userland \ Meta Ports Ladybird Tests Kernel) $ perl -pie 's/\bDeprecatedString\b/ByteString/g; s/deprecated_string/byte_string/g' $xs $ clang-format --style=file -i \ $(git diff --name-only | grep \.cpp\|\.h) $ gn format $(git ls-files '*.gn' '*.gni')
2023-12-16 17:49:34 +03:30
auto result = execute(database, ByteString::formatted("INSERT INTO TestSchema.TestTable VALUES ( 'T{}', {} );", count, count));
LibSQL: Partially implement the UPDATE command This implements enough to update rows filtered by a WHERE clause.
2022-12-05 07:55:21 -05:00
EXPECT_EQ(result.size(), 1u);
}
execute(database, "UPDATE TestSchema.TestTable SET IntColumn=123456;");
auto result = execute(database, "SELECT IntColumn FROM TestSchema.TestTable ORDER BY IntColumn;");
EXPECT_EQ(result.size(), 10u);
for (auto i = 0u; i < 10; ++i)
EXPECT_EQ(result[i].row[0], 123456);
}
{
LibSQL+SQLServer: Remove Core::EventReceiver parent from SQL::Database This relationship was only used to provide factory methods for the database.
2023-08-07 11:03:42 -04:00
auto database = MUST(SQL::Database::create(db_name));
Tests: Prefer TRY_OR_FAIL() and MUST() over EXPECT(!.is_error()) Note that in some cases (in particular SQL::Result and PDFErrorOr), there is no Formatter defined for the error type, hence TRY_OR_FAIL cannot work as-is. Furthermore, this commit leaves untouched the places where MUST could be replaced by TRY_OR_FAIL. Inspired by: https://github.com/SerenityOS/serenity/pull/18710#discussion_r1186892445
2023-05-07 20:14:06 +02:00
MUST(database->open());
LibSQL: Partially implement the UPDATE command This implements enough to update rows filtered by a WHERE clause.
2022-12-05 07:55:21 -05:00
auto result = execute(database, "SELECT IntColumn FROM TestSchema.TestTable ORDER BY IntColumn;");
EXPECT_EQ(result.size(), 10u);
for (auto i = 0u; i < 10; ++i)
EXPECT_EQ(result[i].row[0], 123456);
}
}
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