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

714 lines
26 KiB
C++
Raw Normal View History

LibSQL+SQLServer: Bare bones INSERT and SELECT statements This patch provides very basic, bare bones implementations of the INSERT and SELECT statements. They are *very* limited: - The only variant of the INSERT statement that currently works is SELECT INTO schema.table (column1, column2, ....) VALUES (value11, value21, ...), (value12, value22, ...), ... where the values are literals. - The SELECT statement is even more limited, and is only provided to allow verification of the INSERT statement. The only form implemented is: SELECT * FROM schema.table These statements required a bit of change in the Statement::execute API. Originally execute only received a Database object as parameter. This is not enough; we now pass an ExecutionContext object which contains the Database, the current result set, and the last Tuple read from the database. This object will undoubtedly evolve over time. This API change dragged SQLServer::SQLStatement into the patch. Another API addition is Expression::evaluate. This method is, unsurprisingly, used to evaluate expressions, like the values in the INSERT statement. Finally, a new test file is added: TestSqlStatementExecution, which tests the currently implemented statements. As the number and flavour of implemented statements grows, this test file will probably have to be restructured.
2021-07-19 19:48:46 -04:00
/*
* Copyright (c) 2021, Jan de Visser <jan@de-visser.net>
LibSQL: Implement DESCRIBE TABLE tests
2021-09-19 21:35:16 +02:00
* Copyright (c) 2021, Mahmoud Mandour <ma.mandourr@gmail.com>
LibSQL+SQLServer: Bare bones INSERT and SELECT statements This patch provides very basic, bare bones implementations of the INSERT and SELECT statements. They are *very* limited: - The only variant of the INSERT statement that currently works is SELECT INTO schema.table (column1, column2, ....) VALUES (value11, value21, ...), (value12, value22, ...), ... where the values are literals. - The SELECT statement is even more limited, and is only provided to allow verification of the INSERT statement. The only form implemented is: SELECT * FROM schema.table These statements required a bit of change in the Statement::execute API. Originally execute only received a Database object as parameter. This is not enough; we now pass an ExecutionContext object which contains the Database, the current result set, and the last Tuple read from the database. This object will undoubtedly evolve over time. This API change dragged SQLServer::SQLStatement into the patch. Another API addition is Expression::evaluate. This method is, unsurprisingly, used to evaluate expressions, like the values in the INSERT statement. Finally, a new test file is added: TestSqlStatementExecution, which tests the currently implemented statements. As the number and flavour of implemented statements grows, this test file will probably have to be restructured.
2021-07-19 19:48:46 -04:00
*
* SPDX-License-Identifier: BSD-2-Clause
*/
#include <unistd.h>
#include <AK/ScopeGuard.h>
#include <LibSQL/AST/Parser.h>
#include <LibSQL/Database.h>
LibSQL+SQLServer: Move LibSQL/SQLResult.[h,cpp] to LibSQL/Result.[h,cpp] Rename the file to match the new class name.
2022-02-09 16:02:49 -05:00
#include <LibSQL/Result.h>
LibSQL+SQLServer: Bare bones INSERT and SELECT statements This patch provides very basic, bare bones implementations of the INSERT and SELECT statements. They are *very* limited: - The only variant of the INSERT statement that currently works is SELECT INTO schema.table (column1, column2, ....) VALUES (value11, value21, ...), (value12, value22, ...), ... where the values are literals. - The SELECT statement is even more limited, and is only provided to allow verification of the INSERT statement. The only form implemented is: SELECT * FROM schema.table These statements required a bit of change in the Statement::execute API. Originally execute only received a Database object as parameter. This is not enough; we now pass an ExecutionContext object which contains the Database, the current result set, and the last Tuple read from the database. This object will undoubtedly evolve over time. This API change dragged SQLServer::SQLStatement into the patch. Another API addition is Expression::evaluate. This method is, unsurprisingly, used to evaluate expressions, like the values in the INSERT statement. Finally, a new test file is added: TestSqlStatementExecution, which tests the currently implemented statements. As the number and flavour of implemented statements grows, this test file will probably have to be restructured.
2021-07-19 19:48:46 -04:00
#include <LibSQL/Row.h>
#include <LibSQL/Value.h>
#include <LibTest/TestCase.h>
namespace {
constexpr const char* db_name = "/tmp/test.db";
LibSQL+SQLServer: Return the new Result class from statement executions We can now TRY anything that returns a SQL::Result or an AK::Error.
2022-02-09 15:57:57 -05:00
SQL::Result execute(NonnullRefPtr<SQL::Database> database, String const& sql)
LibSQL+SQLServer: Bare bones INSERT and SELECT statements This patch provides very basic, bare bones implementations of the INSERT and SELECT statements. They are *very* limited: - The only variant of the INSERT statement that currently works is SELECT INTO schema.table (column1, column2, ....) VALUES (value11, value21, ...), (value12, value22, ...), ... where the values are literals. - The SELECT statement is even more limited, and is only provided to allow verification of the INSERT statement. The only form implemented is: SELECT * FROM schema.table These statements required a bit of change in the Statement::execute API. Originally execute only received a Database object as parameter. This is not enough; we now pass an ExecutionContext object which contains the Database, the current result set, and the last Tuple read from the database. This object will undoubtedly evolve over time. This API change dragged SQLServer::SQLStatement into the patch. Another API addition is Expression::evaluate. This method is, unsurprisingly, used to evaluate expressions, like the values in the INSERT statement. Finally, a new test file is added: TestSqlStatementExecution, which tests the currently implemented statements. As the number and flavour of implemented statements grows, this test file will probably have to be restructured.
2021-07-19 19:48:46 -04:00
{
auto parser = SQL::AST::Parser(SQL::AST::Lexer(sql));
auto statement = parser.next_statement();
EXPECT(!parser.has_errors());
LibSQL Tests: Add tests for `SELECT ... WHERE ...`
2021-10-23 10:47:12 -04:00
if (parser.has_errors())
Everywhere: Fix format-vulnerabilities Command used: grep -Pirn '(out|warn)ln\((?!["\)]|format,|stderr,|stdout,|output, ")' \ AK Kernel/ Tests/ Userland/ (Plus some manual reviewing.) Let's pick ArgsParser as an example: outln(file, m_general_help); This will fail at runtime if the general help happens to contain braces. Even if this transformation turns out to be unnecessary in a place or two, this way the code is "more obviously" correct.
2021-09-09 17:06:15 +02:00
outln("{}", parser.errors()[0].to_string());
LibSQL: Add current statement to the ExecutionContext Because SQL is the craptastic language that it is, sometimes expressions need to know details about the calling statement. For example the tables in the 'FROM' clause may be needed to determine which columns are referenced in 'WHERE' expressions. So the current statement is added to the ExecutionContext and a new 'execute' overload on Statement is created which takes the Database and the Statement and builds an ExecutionContaxt from those.
2021-11-02 16:43:57 -04:00
auto result = statement->execute(move(database));
LibSQL+SQLServer: Return the new Result class from statement executions We can now TRY anything that returns a SQL::Result or an AK::Error.
2022-02-09 15:57:57 -05:00
if (result.is_error())
outln("{}", result.error_string());
LibSQL+SQLServer: Bare bones INSERT and SELECT statements This patch provides very basic, bare bones implementations of the INSERT and SELECT statements. They are *very* limited: - The only variant of the INSERT statement that currently works is SELECT INTO schema.table (column1, column2, ....) VALUES (value11, value21, ...), (value12, value22, ...), ... where the values are literals. - The SELECT statement is even more limited, and is only provided to allow verification of the INSERT statement. The only form implemented is: SELECT * FROM schema.table These statements required a bit of change in the Statement::execute API. Originally execute only received a Database object as parameter. This is not enough; we now pass an ExecutionContext object which contains the Database, the current result set, and the last Tuple read from the database. This object will undoubtedly evolve over time. This API change dragged SQLServer::SQLStatement into the patch. Another API addition is Expression::evaluate. This method is, unsurprisingly, used to evaluate expressions, like the values in the INSERT statement. Finally, a new test file is added: TestSqlStatementExecution, which tests the currently implemented statements. As the number and flavour of implemented statements grows, this test file will probably have to be restructured.
2021-07-19 19:48:46 -04:00
return result;
}
void create_schema(NonnullRefPtr<SQL::Database> database)
{
auto result = execute(database, "CREATE SCHEMA TestSchema;");
LibSQL+SQLServer: Return the new Result class from statement executions We can now TRY anything that returns a SQL::Result or an AK::Error.
2022-02-09 15:57:57 -05:00
EXPECT(!result.is_error());
EXPECT(result.inserted() == 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
}
void create_table(NonnullRefPtr<SQL::Database> database)
{
create_schema(database);
auto result = execute(database, "CREATE TABLE TestSchema.TestTable ( TextColumn text, IntColumn integer );");
LibSQL+SQLServer: Return the new Result class from statement executions We can now TRY anything that returns a SQL::Result or an AK::Error.
2022-02-09 15:57:57 -05:00
EXPECT(!result.is_error());
EXPECT(result.inserted() == 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: 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: Return the new Result class from statement executions We can now TRY anything that returns a SQL::Result or an AK::Error.
2022-02-09 15:57:57 -05:00
EXPECT(!result.is_error());
EXPECT(result.inserted() == 1);
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: Return the new Result class from statement executions We can now TRY anything that returns a SQL::Result or an AK::Error.
2022-02-09 15:57:57 -05:00
EXPECT(!result.is_error());
EXPECT(result.inserted() == 1);
LibSQL: Implement table joins This patch introduces table joins. It uses a pretty dumb algorithm- starting with a singleton '__unity__' row consisting of a single boolean value, a cartesian product of all tables in the 'FROM' clause is built. This cartesian product is then filtered through the 'WHERE' clause, again without any smarts just using brute force. This patch required a bunch of busy work to allow for example the ColumnNameExpression having to deal with multiple tables potentially having columns with the same name.
2021-11-02 16:49:54 -04:00
}
LibSQL+SQLServer: Bare bones INSERT and SELECT statements This patch provides very basic, bare bones implementations of the INSERT and SELECT statements. They are *very* limited: - The only variant of the INSERT statement that currently works is SELECT INTO schema.table (column1, column2, ....) VALUES (value11, value21, ...), (value12, value22, ...), ... where the values are literals. - The SELECT statement is even more limited, and is only provided to allow verification of the INSERT statement. The only form implemented is: SELECT * FROM schema.table These statements required a bit of change in the Statement::execute API. Originally execute only received a Database object as parameter. This is not enough; we now pass an ExecutionContext object which contains the Database, the current result set, and the last Tuple read from the database. This object will undoubtedly evolve over time. This API change dragged SQLServer::SQLStatement into the patch. Another API addition is Expression::evaluate. This method is, unsurprisingly, used to evaluate expressions, like the values in the INSERT statement. Finally, a new test file is added: TestSqlStatementExecution, which tests the currently implemented statements. As the number and flavour of implemented statements grows, this test file will probably have to be restructured.
2021-07-19 19:48:46 -04:00
TEST_CASE(create_schema)
{
ScopeGuard guard([]() { unlink(db_name); });
auto database = SQL::Database::construct(db_name);
LibSQL: Improve error handling The handling of filesystem level errors was basically non-existing or consisting of `VERIFY_NOT_REACHED` assertions. Addressed this by * Adding `open` methods to `Heap` and `Database` which return errors. * Changing the interface of methods of these classes and clients downstream to propagate these errors. The constructors of `Heap` and `Database` don't open the underlying filesystem file anymore. The SQL statement handlers return an `SQLErrorCode::InternalError` error code if an error comes back from the lower levels. Note that some of these errors are things like duplicate index entry errors that should be caught before the SQL layer attempts to actually update the database. Added tests to catch attempts to open weird or non-existent files as databases. Finally, in between me writing this patch and submitting the PR the AK::Result<Foo, Bar> template got deprecated in favour of ErrorOr<Foo>. This resulted in more busywork.
2021-11-05 19:05:59 -04:00
EXPECT(!database->open().is_error());
LibSQL+SQLServer: Bare bones INSERT and SELECT statements This patch provides very basic, bare bones implementations of the INSERT and SELECT statements. They are *very* limited: - The only variant of the INSERT statement that currently works is SELECT INTO schema.table (column1, column2, ....) VALUES (value11, value21, ...), (value12, value22, ...), ... where the values are literals. - The SELECT statement is even more limited, and is only provided to allow verification of the INSERT statement. The only form implemented is: SELECT * FROM schema.table These statements required a bit of change in the Statement::execute API. Originally execute only received a Database object as parameter. This is not enough; we now pass an ExecutionContext object which contains the Database, the current result set, and the last Tuple read from the database. This object will undoubtedly evolve over time. This API change dragged SQLServer::SQLStatement into the patch. Another API addition is Expression::evaluate. This method is, unsurprisingly, used to evaluate expressions, like the values in the INSERT statement. Finally, a new test file is added: TestSqlStatementExecution, which tests the currently implemented statements. As the number and flavour of implemented statements grows, this test file will probably have to be restructured.
2021-07-19 19:48:46 -04:00
create_schema(database);
LibSQL: Improve error handling The handling of filesystem level errors was basically non-existing or consisting of `VERIFY_NOT_REACHED` assertions. Addressed this by * Adding `open` methods to `Heap` and `Database` which return errors. * Changing the interface of methods of these classes and clients downstream to propagate these errors. The constructors of `Heap` and `Database` don't open the underlying filesystem file anymore. The SQL statement handlers return an `SQLErrorCode::InternalError` error code if an error comes back from the lower levels. Note that some of these errors are things like duplicate index entry errors that should be caught before the SQL layer attempts to actually update the database. Added tests to catch attempts to open weird or non-existent files as databases. Finally, in between me writing this patch and submitting the PR the AK::Result<Foo, Bar> template got deprecated in favour of ErrorOr<Foo>. This resulted in more busywork.
2021-11-05 19:05:59 -04:00
auto schema_or_error = database->get_schema("TESTSCHEMA");
EXPECT(!schema_or_error.is_error());
EXPECT(schema_or_error.value());
LibSQL+SQLServer: Bare bones INSERT and SELECT statements This patch provides very basic, bare bones implementations of the INSERT and SELECT statements. They are *very* limited: - The only variant of the INSERT statement that currently works is SELECT INTO schema.table (column1, column2, ....) VALUES (value11, value21, ...), (value12, value22, ...), ... where the values are literals. - The SELECT statement is even more limited, and is only provided to allow verification of the INSERT statement. The only form implemented is: SELECT * FROM schema.table These statements required a bit of change in the Statement::execute API. Originally execute only received a Database object as parameter. This is not enough; we now pass an ExecutionContext object which contains the Database, the current result set, and the last Tuple read from the database. This object will undoubtedly evolve over time. This API change dragged SQLServer::SQLStatement into the patch. Another API addition is Expression::evaluate. This method is, unsurprisingly, used to evaluate expressions, like the values in the INSERT statement. Finally, a new test file is added: TestSqlStatementExecution, which tests the currently implemented statements. As the number and flavour of implemented statements grows, this test file will probably have to be restructured.
2021-07-19 19:48:46 -04:00
}
TEST_CASE(create_table)
{
ScopeGuard guard([]() { unlink(db_name); });
auto database = SQL::Database::construct(db_name);
LibSQL: Improve error handling The handling of filesystem level errors was basically non-existing or consisting of `VERIFY_NOT_REACHED` assertions. Addressed this by * Adding `open` methods to `Heap` and `Database` which return errors. * Changing the interface of methods of these classes and clients downstream to propagate these errors. The constructors of `Heap` and `Database` don't open the underlying filesystem file anymore. The SQL statement handlers return an `SQLErrorCode::InternalError` error code if an error comes back from the lower levels. Note that some of these errors are things like duplicate index entry errors that should be caught before the SQL layer attempts to actually update the database. Added tests to catch attempts to open weird or non-existent files as databases. Finally, in between me writing this patch and submitting the PR the AK::Result<Foo, Bar> template got deprecated in favour of ErrorOr<Foo>. This resulted in more busywork.
2021-11-05 19:05:59 -04:00
EXPECT(!database->open().is_error());
LibSQL+SQLServer: Bare bones INSERT and SELECT statements This patch provides very basic, bare bones implementations of the INSERT and SELECT statements. They are *very* limited: - The only variant of the INSERT statement that currently works is SELECT INTO schema.table (column1, column2, ....) VALUES (value11, value21, ...), (value12, value22, ...), ... where the values are literals. - The SELECT statement is even more limited, and is only provided to allow verification of the INSERT statement. The only form implemented is: SELECT * FROM schema.table These statements required a bit of change in the Statement::execute API. Originally execute only received a Database object as parameter. This is not enough; we now pass an ExecutionContext object which contains the Database, the current result set, and the last Tuple read from the database. This object will undoubtedly evolve over time. This API change dragged SQLServer::SQLStatement into the patch. Another API addition is Expression::evaluate. This method is, unsurprisingly, used to evaluate expressions, like the values in the INSERT statement. Finally, a new test file is added: TestSqlStatementExecution, which tests the currently implemented statements. As the number and flavour of implemented statements grows, this test file will probably have to be restructured.
2021-07-19 19:48:46 -04:00
create_table(database);
LibSQL: Improve error handling The handling of filesystem level errors was basically non-existing or consisting of `VERIFY_NOT_REACHED` assertions. Addressed this by * Adding `open` methods to `Heap` and `Database` which return errors. * Changing the interface of methods of these classes and clients downstream to propagate these errors. The constructors of `Heap` and `Database` don't open the underlying filesystem file anymore. The SQL statement handlers return an `SQLErrorCode::InternalError` error code if an error comes back from the lower levels. Note that some of these errors are things like duplicate index entry errors that should be caught before the SQL layer attempts to actually update the database. Added tests to catch attempts to open weird or non-existent files as databases. Finally, in between me writing this patch and submitting the PR the AK::Result<Foo, Bar> template got deprecated in favour of ErrorOr<Foo>. This resulted in more busywork.
2021-11-05 19:05:59 -04:00
auto table_or_error = database->get_table("TESTSCHEMA", "TESTTABLE");
EXPECT(!table_or_error.is_error());
EXPECT(table_or_error.value());
LibSQL+SQLServer: Bare bones INSERT and SELECT statements This patch provides very basic, bare bones implementations of the INSERT and SELECT statements. They are *very* limited: - The only variant of the INSERT statement that currently works is SELECT INTO schema.table (column1, column2, ....) VALUES (value11, value21, ...), (value12, value22, ...), ... where the values are literals. - The SELECT statement is even more limited, and is only provided to allow verification of the INSERT statement. The only form implemented is: SELECT * FROM schema.table These statements required a bit of change in the Statement::execute API. Originally execute only received a Database object as parameter. This is not enough; we now pass an ExecutionContext object which contains the Database, the current result set, and the last Tuple read from the database. This object will undoubtedly evolve over time. This API change dragged SQLServer::SQLStatement into the patch. Another API addition is Expression::evaluate. This method is, unsurprisingly, used to evaluate expressions, like the values in the INSERT statement. Finally, a new test file is added: TestSqlStatementExecution, which tests the currently implemented statements. As the number and flavour of implemented statements grows, this test file will probably have to be restructured.
2021-07-19 19:48:46 -04:00
}
TEST_CASE(insert_into_table)
{
ScopeGuard guard([]() { unlink(db_name); });
auto database = SQL::Database::construct(db_name);
LibSQL: Improve error handling The handling of filesystem level errors was basically non-existing or consisting of `VERIFY_NOT_REACHED` assertions. Addressed this by * Adding `open` methods to `Heap` and `Database` which return errors. * Changing the interface of methods of these classes and clients downstream to propagate these errors. The constructors of `Heap` and `Database` don't open the underlying filesystem file anymore. The SQL statement handlers return an `SQLErrorCode::InternalError` error code if an error comes back from the lower levels. Note that some of these errors are things like duplicate index entry errors that should be caught before the SQL layer attempts to actually update the database. Added tests to catch attempts to open weird or non-existent files as databases. Finally, in between me writing this patch and submitting the PR the AK::Result<Foo, Bar> template got deprecated in favour of ErrorOr<Foo>. This resulted in more busywork.
2021-11-05 19:05:59 -04:00
EXPECT(!database->open().is_error());
LibSQL+SQLServer: Bare bones INSERT and SELECT statements This patch provides very basic, bare bones implementations of the INSERT and SELECT statements. They are *very* limited: - The only variant of the INSERT statement that currently works is SELECT INTO schema.table (column1, column2, ....) VALUES (value11, value21, ...), (value12, value22, ...), ... where the values are literals. - The SELECT statement is even more limited, and is only provided to allow verification of the INSERT statement. The only form implemented is: SELECT * FROM schema.table These statements required a bit of change in the Statement::execute API. Originally execute only received a Database object as parameter. This is not enough; we now pass an ExecutionContext object which contains the Database, the current result set, and the last Tuple read from the database. This object will undoubtedly evolve over time. This API change dragged SQLServer::SQLStatement into the patch. Another API addition is Expression::evaluate. This method is, unsurprisingly, used to evaluate expressions, like the values in the INSERT statement. Finally, a new test file is added: TestSqlStatementExecution, which tests the currently implemented statements. As the number and flavour of implemented statements grows, this test file will probably have to be restructured.
2021-07-19 19:48:46 -04:00
create_table(database);
auto result = execute(database, "INSERT INTO TestSchema.TestTable ( TextColumn, IntColumn ) VALUES ( 'Test', 42 );");
LibSQL+SQLServer: Return the new Result class from statement executions We can now TRY anything that returns a SQL::Result or an AK::Error.
2022-02-09 15:57:57 -05:00
EXPECT(!result.is_error());
EXPECT(result.inserted() == 1);
LibSQL+SQLServer: Bare bones INSERT and SELECT statements This patch provides very basic, bare bones implementations of the INSERT and SELECT statements. They are *very* limited: - The only variant of the INSERT statement that currently works is SELECT INTO schema.table (column1, column2, ....) VALUES (value11, value21, ...), (value12, value22, ...), ... where the values are literals. - The SELECT statement is even more limited, and is only provided to allow verification of the INSERT statement. The only form implemented is: SELECT * FROM schema.table These statements required a bit of change in the Statement::execute API. Originally execute only received a Database object as parameter. This is not enough; we now pass an ExecutionContext object which contains the Database, the current result set, and the last Tuple read from the database. This object will undoubtedly evolve over time. This API change dragged SQLServer::SQLStatement into the patch. Another API addition is Expression::evaluate. This method is, unsurprisingly, used to evaluate expressions, like the values in the INSERT statement. Finally, a new test file is added: TestSqlStatementExecution, which tests the currently implemented statements. As the number and flavour of implemented statements grows, this test file will probably have to be restructured.
2021-07-19 19:48:46 -04:00
LibSQL: Improve error handling The handling of filesystem level errors was basically non-existing or consisting of `VERIFY_NOT_REACHED` assertions. Addressed this by * Adding `open` methods to `Heap` and `Database` which return errors. * Changing the interface of methods of these classes and clients downstream to propagate these errors. The constructors of `Heap` and `Database` don't open the underlying filesystem file anymore. The SQL statement handlers return an `SQLErrorCode::InternalError` error code if an error comes back from the lower levels. Note that some of these errors are things like duplicate index entry errors that should be caught before the SQL layer attempts to actually update the database. Added tests to catch attempts to open weird or non-existent files as databases. Finally, in between me writing this patch and submitting the PR the AK::Result<Foo, Bar> template got deprecated in favour of ErrorOr<Foo>. This resulted in more busywork.
2021-11-05 19:05:59 -04:00
auto table_or_error = database->get_table("TESTSCHEMA", "TESTTABLE");
EXPECT(!table_or_error.is_error());
auto table = table_or_error.value();
LibSQL+SQLServer: Bare bones INSERT and SELECT statements This patch provides very basic, bare bones implementations of the INSERT and SELECT statements. They are *very* limited: - The only variant of the INSERT statement that currently works is SELECT INTO schema.table (column1, column2, ....) VALUES (value11, value21, ...), (value12, value22, ...), ... where the values are literals. - The SELECT statement is even more limited, and is only provided to allow verification of the INSERT statement. The only form implemented is: SELECT * FROM schema.table These statements required a bit of change in the Statement::execute API. Originally execute only received a Database object as parameter. This is not enough; we now pass an ExecutionContext object which contains the Database, the current result set, and the last Tuple read from the database. This object will undoubtedly evolve over time. This API change dragged SQLServer::SQLStatement into the patch. Another API addition is Expression::evaluate. This method is, unsurprisingly, used to evaluate expressions, like the values in the INSERT statement. Finally, a new test file is added: TestSqlStatementExecution, which tests the currently implemented statements. As the number and flavour of implemented statements grows, this test file will probably have to be restructured.
2021-07-19 19:48:46 -04:00
int count = 0;
LibSQL: Improve error handling The handling of filesystem level errors was basically non-existing or consisting of `VERIFY_NOT_REACHED` assertions. Addressed this by * Adding `open` methods to `Heap` and `Database` which return errors. * Changing the interface of methods of these classes and clients downstream to propagate these errors. The constructors of `Heap` and `Database` don't open the underlying filesystem file anymore. The SQL statement handlers return an `SQLErrorCode::InternalError` error code if an error comes back from the lower levels. Note that some of these errors are things like duplicate index entry errors that should be caught before the SQL layer attempts to actually update the database. Added tests to catch attempts to open weird or non-existent files as databases. Finally, in between me writing this patch and submitting the PR the AK::Result<Foo, Bar> template got deprecated in favour of ErrorOr<Foo>. This resulted in more busywork.
2021-11-05 19:05:59 -04:00
auto rows_or_error = database->select_all(*table);
EXPECT(!rows_or_error.is_error());
for (auto& row : rows_or_error.value()) {
LibSQL+SQLServer: Bare bones INSERT and SELECT statements This patch provides very basic, bare bones implementations of the INSERT and SELECT statements. They are *very* limited: - The only variant of the INSERT statement that currently works is SELECT INTO schema.table (column1, column2, ....) VALUES (value11, value21, ...), (value12, value22, ...), ... where the values are literals. - The SELECT statement is even more limited, and is only provided to allow verification of the INSERT statement. The only form implemented is: SELECT * FROM schema.table These statements required a bit of change in the Statement::execute API. Originally execute only received a Database object as parameter. This is not enough; we now pass an ExecutionContext object which contains the Database, the current result set, and the last Tuple read from the database. This object will undoubtedly evolve over time. This API change dragged SQLServer::SQLStatement into the patch. Another API addition is Expression::evaluate. This method is, unsurprisingly, used to evaluate expressions, like the values in the INSERT statement. Finally, a new test file is added: TestSqlStatementExecution, which tests the currently implemented statements. As the number and flavour of implemented statements grows, this test file will probably have to be restructured.
2021-07-19 19:48:46 -04:00
EXPECT_EQ(row["TEXTCOLUMN"].to_string(), "Test");
EXPECT_EQ(row["INTCOLUMN"].to_int().value(), 42);
count++;
}
EXPECT_EQ(count, 1);
}
LibSQL: Test INSERT statement with wrong data types
2021-09-17 20:48:54 +02:00
TEST_CASE(insert_into_table_wrong_data_types)
{
ScopeGuard guard([]() { unlink(db_name); });
auto database = SQL::Database::construct(db_name);
LibSQL: Improve error handling The handling of filesystem level errors was basically non-existing or consisting of `VERIFY_NOT_REACHED` assertions. Addressed this by * Adding `open` methods to `Heap` and `Database` which return errors. * Changing the interface of methods of these classes and clients downstream to propagate these errors. The constructors of `Heap` and `Database` don't open the underlying filesystem file anymore. The SQL statement handlers return an `SQLErrorCode::InternalError` error code if an error comes back from the lower levels. Note that some of these errors are things like duplicate index entry errors that should be caught before the SQL layer attempts to actually update the database. Added tests to catch attempts to open weird or non-existent files as databases. Finally, in between me writing this patch and submitting the PR the AK::Result<Foo, Bar> template got deprecated in favour of ErrorOr<Foo>. This resulted in more busywork.
2021-11-05 19:05:59 -04:00
EXPECT(!database->open().is_error());
LibSQL: Test INSERT statement with wrong data types
2021-09-17 20:48:54 +02:00
create_table(database);
auto result = execute(database, "INSERT INTO TestSchema.TestTable ( TextColumn, IntColumn ) VALUES (43, 'Test_2');");
LibSQL+SQLServer: Return the new Result class from statement executions We can now TRY anything that returns a SQL::Result or an AK::Error.
2022-02-09 15:57:57 -05:00
EXPECT(result.inserted() == 0);
EXPECT(result.error() == SQL::SQLErrorCode::InvalidValueType);
LibSQL: Test INSERT statement with wrong data types
2021-09-17 20:48:54 +02:00
}
TEST_CASE(insert_into_table_multiple_tuples_wrong_data_types)
{
ScopeGuard guard([]() { unlink(db_name); });
auto database = SQL::Database::construct(db_name);
LibSQL: Improve error handling The handling of filesystem level errors was basically non-existing or consisting of `VERIFY_NOT_REACHED` assertions. Addressed this by * Adding `open` methods to `Heap` and `Database` which return errors. * Changing the interface of methods of these classes and clients downstream to propagate these errors. The constructors of `Heap` and `Database` don't open the underlying filesystem file anymore. The SQL statement handlers return an `SQLErrorCode::InternalError` error code if an error comes back from the lower levels. Note that some of these errors are things like duplicate index entry errors that should be caught before the SQL layer attempts to actually update the database. Added tests to catch attempts to open weird or non-existent files as databases. Finally, in between me writing this patch and submitting the PR the AK::Result<Foo, Bar> template got deprecated in favour of ErrorOr<Foo>. This resulted in more busywork.
2021-11-05 19:05:59 -04:00
EXPECT(!database->open().is_error());
LibSQL: Test INSERT statement with wrong data types
2021-09-17 20:48:54 +02:00
create_table(database);
auto result = execute(database, "INSERT INTO TestSchema.TestTable ( TextColumn, IntColumn ) VALUES ('Test_1', 42), (43, 'Test_2');");
LibSQL+SQLServer: Return the new Result class from statement executions We can now TRY anything that returns a SQL::Result or an AK::Error.
2022-02-09 15:57:57 -05:00
EXPECT(result.inserted() == 0);
EXPECT(result.error() == SQL::SQLErrorCode::InvalidValueType);
LibSQL: Test INSERT statement with wrong data types
2021-09-17 20:48:54 +02:00
}
LibSQL: Test INSERT statement with wrong number of values
2021-09-17 20:49:49 +02:00
TEST_CASE(insert_wrong_number_of_values)
{
ScopeGuard guard([]() { unlink(db_name); });
auto database = SQL::Database::construct(db_name);
LibSQL: Improve error handling The handling of filesystem level errors was basically non-existing or consisting of `VERIFY_NOT_REACHED` assertions. Addressed this by * Adding `open` methods to `Heap` and `Database` which return errors. * Changing the interface of methods of these classes and clients downstream to propagate these errors. The constructors of `Heap` and `Database` don't open the underlying filesystem file anymore. The SQL statement handlers return an `SQLErrorCode::InternalError` error code if an error comes back from the lower levels. Note that some of these errors are things like duplicate index entry errors that should be caught before the SQL layer attempts to actually update the database. Added tests to catch attempts to open weird or non-existent files as databases. Finally, in between me writing this patch and submitting the PR the AK::Result<Foo, Bar> template got deprecated in favour of ErrorOr<Foo>. This resulted in more busywork.
2021-11-05 19:05:59 -04:00
EXPECT(!database->open().is_error());
LibSQL: Test INSERT statement with wrong number of values
2021-09-17 20:49:49 +02:00
create_table(database);
auto result = execute(database, "INSERT INTO TestSchema.TestTable VALUES ( 42 );");
LibSQL+SQLServer: Return the new Result class from statement executions We can now TRY anything that returns a SQL::Result or an AK::Error.
2022-02-09 15:57:57 -05:00
EXPECT(result.error() == SQL::SQLErrorCode::InvalidNumberOfValues);
EXPECT(result.inserted() == 0);
LibSQL: Test INSERT statement with wrong number of values
2021-09-17 20:49:49 +02:00
}
LibSQL: Gracefully react to unimplemented valid SQL Fixes a crash that was caused by a syntax error which is difficult to catch by the parser: usually identifiers are accepted in column lists, but they are not in a list of column values to be inserted in an INSERT. Fixed this by putting in a heuristic check; we probably need a better way to do this. Included tests for this case. Also introduced a new SQL Error code, `NotYetImplemented`, and return that instead of crashing when encountering unimplemented SQL.
2021-11-13 17:30:29 -05:00
TEST_CASE(insert_identifier_as_value)
{
ScopeGuard guard([]() { unlink(db_name); });
auto database = SQL::Database::construct(db_name);
EXPECT(!database->open().is_error());
create_table(database);
auto result = execute(database, "INSERT INTO TestSchema.TestTable VALUES ( identifier, 42 );");
LibSQL+SQLServer: Return the new Result class from statement executions We can now TRY anything that returns a SQL::Result or an AK::Error.
2022-02-09 15:57:57 -05:00
EXPECT(result.error() == SQL::SQLErrorCode::SyntaxError);
EXPECT(result.inserted() == 0);
LibSQL: Gracefully react to unimplemented valid SQL Fixes a crash that was caused by a syntax error which is difficult to catch by the parser: usually identifiers are accepted in column lists, but they are not in a list of column values to be inserted in an INSERT. Fixed this by putting in a heuristic check; we probably need a better way to do this. Included tests for this case. Also introduced a new SQL Error code, `NotYetImplemented`, and return that instead of crashing when encountering unimplemented SQL.
2021-11-13 17:30:29 -05:00
}
TEST_CASE(insert_quoted_identifier_as_value)
{
ScopeGuard guard([]() { unlink(db_name); });
auto database = SQL::Database::construct(db_name);
EXPECT(!database->open().is_error());
create_table(database);
auto result = execute(database, "INSERT INTO TestSchema.TestTable VALUES ( \"QuotedIdentifier\", 42 );");
LibSQL+SQLServer: Return the new Result class from statement executions We can now TRY anything that returns a SQL::Result or an AK::Error.
2022-02-09 15:57:57 -05:00
EXPECT(result.error() == SQL::SQLErrorCode::SyntaxError);
EXPECT(result.inserted() == 0);
LibSQL: Gracefully react to unimplemented valid SQL Fixes a crash that was caused by a syntax error which is difficult to catch by the parser: usually identifiers are accepted in column lists, but they are not in a list of column values to be inserted in an INSERT. Fixed this by putting in a heuristic check; we probably need a better way to do this. Included tests for this case. Also introduced a new SQL Error code, `NotYetImplemented`, and return that instead of crashing when encountering unimplemented SQL.
2021-11-13 17:30:29 -05:00
}
LibSQL: Add an INSERT without column names test This adds a passing test of an insert statement that contains no column names and assumes full tuple input
2021-09-17 23:29:28 +02:00
TEST_CASE(insert_without_column_names)
{
ScopeGuard guard([]() { unlink(db_name); });
auto database = SQL::Database::construct(db_name);
LibSQL: Improve error handling The handling of filesystem level errors was basically non-existing or consisting of `VERIFY_NOT_REACHED` assertions. Addressed this by * Adding `open` methods to `Heap` and `Database` which return errors. * Changing the interface of methods of these classes and clients downstream to propagate these errors. The constructors of `Heap` and `Database` don't open the underlying filesystem file anymore. The SQL statement handlers return an `SQLErrorCode::InternalError` error code if an error comes back from the lower levels. Note that some of these errors are things like duplicate index entry errors that should be caught before the SQL layer attempts to actually update the database. Added tests to catch attempts to open weird or non-existent files as databases. Finally, in between me writing this patch and submitting the PR the AK::Result<Foo, Bar> template got deprecated in favour of ErrorOr<Foo>. This resulted in more busywork.
2021-11-05 19:05:59 -04:00
EXPECT(!database->open().is_error());
LibSQL: Add an INSERT without column names test This adds a passing test of an insert statement that contains no column names and assumes full tuple input
2021-09-17 23:29:28 +02:00
create_table(database);
auto result = execute(database, "INSERT INTO TestSchema.TestTable VALUES ('Test_1', 42), ('Test_2', 43);");
LibSQL+SQLServer: Return the new Result class from statement executions We can now TRY anything that returns a SQL::Result or an AK::Error.
2022-02-09 15:57:57 -05:00
EXPECT(!result.is_error());
EXPECT(result.inserted() == 2);
LibSQL: Add an INSERT without column names test This adds a passing test of an insert statement that contains no column names and assumes full tuple input
2021-09-17 23:29:28 +02:00
LibSQL: Improve error handling The handling of filesystem level errors was basically non-existing or consisting of `VERIFY_NOT_REACHED` assertions. Addressed this by * Adding `open` methods to `Heap` and `Database` which return errors. * Changing the interface of methods of these classes and clients downstream to propagate these errors. The constructors of `Heap` and `Database` don't open the underlying filesystem file anymore. The SQL statement handlers return an `SQLErrorCode::InternalError` error code if an error comes back from the lower levels. Note that some of these errors are things like duplicate index entry errors that should be caught before the SQL layer attempts to actually update the database. Added tests to catch attempts to open weird or non-existent files as databases. Finally, in between me writing this patch and submitting the PR the AK::Result<Foo, Bar> template got deprecated in favour of ErrorOr<Foo>. This resulted in more busywork.
2021-11-05 19:05:59 -04:00
auto table_or_error = database->get_table("TESTSCHEMA", "TESTTABLE");
EXPECT(!table_or_error.is_error());
auto rows_or_error = database->select_all(*(table_or_error.value()));
EXPECT(!rows_or_error.is_error());
EXPECT_EQ(rows_or_error.value().size(), 2u);
LibSQL: Add an INSERT without column names test This adds a passing test of an insert statement that contains no column names and assumes full tuple input
2021-09-17 23:29:28 +02:00
}
LibSQL: Do not crash when SELECTing from an empty table The crash was caused by getting the first element of an empty vector.
2022-02-09 17:10:08 -05:00
TEST_CASE(select_from_empty_table)
{
ScopeGuard guard([]() { unlink(db_name); });
auto database = SQL::Database::construct(db_name);
EXPECT(!database->open().is_error());
create_table(database);
auto result = execute(database, "SELECT * FROM TestSchema.TestTable;");
EXPECT(!result.is_error());
EXPECT(!result.has_results());
}
LibSQL+SQLServer: Bare bones INSERT and SELECT statements This patch provides very basic, bare bones implementations of the INSERT and SELECT statements. They are *very* limited: - The only variant of the INSERT statement that currently works is SELECT INTO schema.table (column1, column2, ....) VALUES (value11, value21, ...), (value12, value22, ...), ... where the values are literals. - The SELECT statement is even more limited, and is only provided to allow verification of the INSERT statement. The only form implemented is: SELECT * FROM schema.table These statements required a bit of change in the Statement::execute API. Originally execute only received a Database object as parameter. This is not enough; we now pass an ExecutionContext object which contains the Database, the current result set, and the last Tuple read from the database. This object will undoubtedly evolve over time. This API change dragged SQLServer::SQLStatement into the patch. Another API addition is Expression::evaluate. This method is, unsurprisingly, used to evaluate expressions, like the values in the INSERT statement. Finally, a new test file is added: TestSqlStatementExecution, which tests the currently implemented statements. As the number and flavour of implemented statements grows, this test file will probably have to be restructured.
2021-07-19 19:48:46 -04:00
TEST_CASE(select_from_table)
{
ScopeGuard guard([]() { unlink(db_name); });
auto database = SQL::Database::construct(db_name);
LibSQL: Improve error handling The handling of filesystem level errors was basically non-existing or consisting of `VERIFY_NOT_REACHED` assertions. Addressed this by * Adding `open` methods to `Heap` and `Database` which return errors. * Changing the interface of methods of these classes and clients downstream to propagate these errors. The constructors of `Heap` and `Database` don't open the underlying filesystem file anymore. The SQL statement handlers return an `SQLErrorCode::InternalError` error code if an error comes back from the lower levels. Note that some of these errors are things like duplicate index entry errors that should be caught before the SQL layer attempts to actually update the database. Added tests to catch attempts to open weird or non-existent files as databases. Finally, in between me writing this patch and submitting the PR the AK::Result<Foo, Bar> template got deprecated in favour of ErrorOr<Foo>. This resulted in more busywork.
2021-11-05 19:05:59 -04:00
EXPECT(!database->open().is_error());
LibSQL+SQLServer: Bare bones INSERT and SELECT statements This patch provides very basic, bare bones implementations of the INSERT and SELECT statements. They are *very* limited: - The only variant of the INSERT statement that currently works is SELECT INTO schema.table (column1, column2, ....) VALUES (value11, value21, ...), (value12, value22, ...), ... where the values are literals. - The SELECT statement is even more limited, and is only provided to allow verification of the INSERT statement. The only form implemented is: SELECT * FROM schema.table These statements required a bit of change in the Statement::execute API. Originally execute only received a Database object as parameter. This is not enough; we now pass an ExecutionContext object which contains the Database, the current result set, and the last Tuple read from the database. This object will undoubtedly evolve over time. This API change dragged SQLServer::SQLStatement into the patch. Another API addition is Expression::evaluate. This method is, unsurprisingly, used to evaluate expressions, like the values in the INSERT statement. Finally, a new test file is added: TestSqlStatementExecution, which tests the currently implemented statements. As the number and flavour of implemented statements grows, this test file will probably have to be restructured.
2021-07-19 19:48:46 -04:00
create_table(database);
LibSQL: Implement table joins This patch introduces table joins. It uses a pretty dumb algorithm- starting with a singleton '__unity__' row consisting of a single boolean value, a cartesian product of all tables in the 'FROM' clause is built. This cartesian product is then filtered through the 'WHERE' clause, again without any smarts just using brute force. This patch required a bunch of busy work to allow for example the ColumnNameExpression having to deal with multiple tables potentially having columns with the same name.
2021-11-02 16:49:54 -04:00
auto result = execute(database,
"INSERT INTO TestSchema.TestTable ( TextColumn, IntColumn ) VALUES "
"( 'Test_1', 42 ), "
"( 'Test_2', 43 ), "
"( 'Test_3', 44 ), "
"( 'Test_4', 45 ), "
"( 'Test_5', 46 );");
LibSQL+SQLServer: Return the new Result class from statement executions We can now TRY anything that returns a SQL::Result or an AK::Error.
2022-02-09 15:57:57 -05:00
EXPECT(!result.is_error());
EXPECT(result.inserted() == 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: Return the new Result class from statement executions We can now TRY anything that returns a SQL::Result or an AK::Error.
2022-02-09 15:57:57 -05:00
EXPECT(!result.is_error());
EXPECT(result.has_results());
EXPECT_EQ(result.results().size(), 5u);
LibSQL+SQLServer: Bare bones INSERT and SELECT statements This patch provides very basic, bare bones implementations of the INSERT and SELECT statements. They are *very* limited: - The only variant of the INSERT statement that currently works is SELECT INTO schema.table (column1, column2, ....) VALUES (value11, value21, ...), (value12, value22, ...), ... where the values are literals. - The SELECT statement is even more limited, and is only provided to allow verification of the INSERT statement. The only form implemented is: SELECT * FROM schema.table These statements required a bit of change in the Statement::execute API. Originally execute only received a Database object as parameter. This is not enough; we now pass an ExecutionContext object which contains the Database, the current result set, and the last Tuple read from the database. This object will undoubtedly evolve over time. This API change dragged SQLServer::SQLStatement into the patch. Another API addition is Expression::evaluate. This method is, unsurprisingly, used to evaluate expressions, like the values in the INSERT statement. Finally, a new test file is added: TestSqlStatementExecution, which tests the currently implemented statements. As the number and flavour of implemented statements grows, this test file will probably have to be restructured.
2021-07-19 19:48:46 -04:00
}
LibSQL Tests: Add tests for `SELECT ... WHERE ...`
2021-10-23 10:47:12 -04:00
TEST_CASE(select_with_column_names)
{
ScopeGuard guard([]() { unlink(db_name); });
auto database = SQL::Database::construct(db_name);
LibSQL: Improve error handling The handling of filesystem level errors was basically non-existing or consisting of `VERIFY_NOT_REACHED` assertions. Addressed this by * Adding `open` methods to `Heap` and `Database` which return errors. * Changing the interface of methods of these classes and clients downstream to propagate these errors. The constructors of `Heap` and `Database` don't open the underlying filesystem file anymore. The SQL statement handlers return an `SQLErrorCode::InternalError` error code if an error comes back from the lower levels. Note that some of these errors are things like duplicate index entry errors that should be caught before the SQL layer attempts to actually update the database. Added tests to catch attempts to open weird or non-existent files as databases. Finally, in between me writing this patch and submitting the PR the AK::Result<Foo, Bar> template got deprecated in favour of ErrorOr<Foo>. This resulted in more busywork.
2021-11-05 19:05:59 -04:00
EXPECT(!database->open().is_error());
LibSQL Tests: Add tests for `SELECT ... WHERE ...`
2021-10-23 10:47:12 -04:00
create_table(database);
LibSQL: Implement table joins This patch introduces table joins. It uses a pretty dumb algorithm- starting with a singleton '__unity__' row consisting of a single boolean value, a cartesian product of all tables in the 'FROM' clause is built. This cartesian product is then filtered through the 'WHERE' clause, again without any smarts just using brute force. This patch required a bunch of busy work to allow for example the ColumnNameExpression having to deal with multiple tables potentially having columns with the same name.
2021-11-02 16:49:54 -04:00
auto result = execute(database,
"INSERT INTO TestSchema.TestTable ( TextColumn, IntColumn ) VALUES "
"( 'Test_1', 42 ), "
"( 'Test_2', 43 ), "
"( 'Test_3', 44 ), "
"( 'Test_4', 45 ), "
"( 'Test_5', 46 );");
LibSQL+SQLServer: Return the new Result class from statement executions We can now TRY anything that returns a SQL::Result or an AK::Error.
2022-02-09 15:57:57 -05:00
EXPECT(!result.is_error());
EXPECT(result.inserted() == 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: Return the new Result class from statement executions We can now TRY anything that returns a SQL::Result or an AK::Error.
2022-02-09 15:57:57 -05:00
EXPECT(!result.is_error());
EXPECT(result.has_results());
EXPECT_EQ(result.results().size(), 5u);
EXPECT_EQ(result.results()[0].row.size(), 1u);
LibSQL Tests: Add tests for `SELECT ... WHERE ...`
2021-10-23 10:47:12 -04:00
}
TEST_CASE(select_with_nonexisting_column_name)
{
ScopeGuard guard([]() { unlink(db_name); });
auto database = SQL::Database::construct(db_name);
LibSQL: Improve error handling The handling of filesystem level errors was basically non-existing or consisting of `VERIFY_NOT_REACHED` assertions. Addressed this by * Adding `open` methods to `Heap` and `Database` which return errors. * Changing the interface of methods of these classes and clients downstream to propagate these errors. The constructors of `Heap` and `Database` don't open the underlying filesystem file anymore. The SQL statement handlers return an `SQLErrorCode::InternalError` error code if an error comes back from the lower levels. Note that some of these errors are things like duplicate index entry errors that should be caught before the SQL layer attempts to actually update the database. Added tests to catch attempts to open weird or non-existent files as databases. Finally, in between me writing this patch and submitting the PR the AK::Result<Foo, Bar> template got deprecated in favour of ErrorOr<Foo>. This resulted in more busywork.
2021-11-05 19:05:59 -04:00
EXPECT(!database->open().is_error());
LibSQL Tests: Add tests for `SELECT ... WHERE ...`
2021-10-23 10:47:12 -04:00
create_table(database);
auto result = execute(database,
"INSERT INTO TestSchema.TestTable ( TextColumn, IntColumn ) VALUES "
"( 'Test_1', 42 ), "
"( 'Test_2', 43 ), "
"( 'Test_3', 44 ), "
"( 'Test_4', 45 ), "
"( 'Test_5', 46 );");
LibSQL+SQLServer: Return the new Result class from statement executions We can now TRY anything that returns a SQL::Result or an AK::Error.
2022-02-09 15:57:57 -05:00
EXPECT(!result.is_error());
EXPECT(result.inserted() == 5);
LibSQL Tests: Add tests for `SELECT ... WHERE ...`
2021-10-23 10:47:12 -04:00
result = execute(database, "SELECT Bogus FROM TestSchema.TestTable;");
LibSQL+SQLServer: Return the new Result class from statement executions We can now TRY anything that returns a SQL::Result or an AK::Error.
2022-02-09 15:57:57 -05:00
EXPECT(result.error() == SQL::SQLErrorCode::ColumnDoesNotExist);
LibSQL Tests: Add tests for `SELECT ... WHERE ...`
2021-10-23 10:47:12 -04:00
}
TEST_CASE(select_with_where)
{
ScopeGuard guard([]() { unlink(db_name); });
auto database = SQL::Database::construct(db_name);
LibSQL: Improve error handling The handling of filesystem level errors was basically non-existing or consisting of `VERIFY_NOT_REACHED` assertions. Addressed this by * Adding `open` methods to `Heap` and `Database` which return errors. * Changing the interface of methods of these classes and clients downstream to propagate these errors. The constructors of `Heap` and `Database` don't open the underlying filesystem file anymore. The SQL statement handlers return an `SQLErrorCode::InternalError` error code if an error comes back from the lower levels. Note that some of these errors are things like duplicate index entry errors that should be caught before the SQL layer attempts to actually update the database. Added tests to catch attempts to open weird or non-existent files as databases. Finally, in between me writing this patch and submitting the PR the AK::Result<Foo, Bar> template got deprecated in favour of ErrorOr<Foo>. This resulted in more busywork.
2021-11-05 19:05:59 -04:00
EXPECT(!database->open().is_error());
LibSQL Tests: Add tests for `SELECT ... WHERE ...`
2021-10-23 10:47:12 -04:00
create_table(database);
auto result = execute(database,
"INSERT INTO TestSchema.TestTable ( TextColumn, IntColumn ) VALUES "
"( 'Test_1', 42 ), "
"( 'Test_2', 43 ), "
"( 'Test_3', 44 ), "
"( 'Test_4', 45 ), "
"( 'Test_5', 46 );");
LibSQL+SQLServer: Return the new Result class from statement executions We can now TRY anything that returns a SQL::Result or an AK::Error.
2022-02-09 15:57:57 -05:00
EXPECT(!result.is_error());
EXPECT(result.inserted() == 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: Return the new Result class from statement executions We can now TRY anything that returns a SQL::Result or an AK::Error.
2022-02-09 15:57:57 -05:00
EXPECT(!result.is_error());
EXPECT(result.has_results());
EXPECT_EQ(result.results().size(), 2u);
for (auto& row : result.results()) {
LibSQL+SQLServer: Implement first cut of SELECT ... ORDER BY foo Ordering is done by replacing the straight Vector holding the query result in the SQLResult object with a dedicated Vector subclass that inserts result rows according to their sort key using a binary search. This is done in the ResultSet class. There are limitations: - "SELECT ... ORDER BY 1" (or 2 or 3 etc) is supposed to sort by the n-th result column. This doesn't work yet - "SELECT ... column-expression alias ... ORDER BY alias" is supposed to sort by the column with the given alias. This doesn't work yet What does work however is something like ```SELECT foo FROM bar SORT BY quux``` i.e. sorted by a column not in the result set. Once functions are supported it should be possible to sort by random functions.
2022-01-12 09:49:43 -05:00
EXPECT(row.row[1].to_int().value() > 44);
LibSQL Tests: Add tests for `SELECT ... WHERE ...`
2021-10-23 10:47:12 -04:00
}
}
LibSQL: Implement table joins This patch introduces table joins. It uses a pretty dumb algorithm- starting with a singleton '__unity__' row consisting of a single boolean value, a cartesian product of all tables in the 'FROM' clause is built. This cartesian product is then filtered through the 'WHERE' clause, again without any smarts just using brute force. This patch required a bunch of busy work to allow for example the ColumnNameExpression having to deal with multiple tables potentially having columns with the same name.
2021-11-02 16:49:54 -04:00
TEST_CASE(select_cross_join)
{
ScopeGuard guard([]() { unlink(db_name); });
auto database = SQL::Database::construct(db_name);
LibSQL: Improve error handling The handling of filesystem level errors was basically non-existing or consisting of `VERIFY_NOT_REACHED` assertions. Addressed this by * Adding `open` methods to `Heap` and `Database` which return errors. * Changing the interface of methods of these classes and clients downstream to propagate these errors. The constructors of `Heap` and `Database` don't open the underlying filesystem file anymore. The SQL statement handlers return an `SQLErrorCode::InternalError` error code if an error comes back from the lower levels. Note that some of these errors are things like duplicate index entry errors that should be caught before the SQL layer attempts to actually update the database. Added tests to catch attempts to open weird or non-existent files as databases. Finally, in between me writing this patch and submitting the PR the AK::Result<Foo, Bar> template got deprecated in favour of ErrorOr<Foo>. This resulted in more busywork.
2021-11-05 19:05:59 -04:00
EXPECT(!database->open().is_error());
LibSQL: Implement table joins This patch introduces table joins. It uses a pretty dumb algorithm- starting with a singleton '__unity__' row consisting of a single boolean value, a cartesian product of all tables in the 'FROM' clause is built. This cartesian product is then filtered through the 'WHERE' clause, again without any smarts just using brute force. This patch required a bunch of busy work to allow for example the ColumnNameExpression having to deal with multiple tables potentially having columns with the same name.
2021-11-02 16:49:54 -04:00
create_two_tables(database);
auto result = execute(database,
"INSERT INTO TestSchema.TestTable1 ( TextColumn1, IntColumn ) VALUES "
"( 'Test_1', 42 ), "
"( 'Test_2', 43 ), "
"( 'Test_3', 44 ), "
"( 'Test_4', 45 ), "
"( 'Test_5', 46 );");
LibSQL+SQLServer: Return the new Result class from statement executions We can now TRY anything that returns a SQL::Result or an AK::Error.
2022-02-09 15:57:57 -05:00
EXPECT(!result.is_error());
EXPECT(result.inserted() == 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: Return the new Result class from statement executions We can now TRY anything that returns a SQL::Result or an AK::Error.
2022-02-09 15:57:57 -05:00
EXPECT(!result.is_error());
EXPECT(result.inserted() == 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: Return the new Result class from statement executions We can now TRY anything that returns a SQL::Result or an AK::Error.
2022-02-09 15:57:57 -05:00
EXPECT(!result.is_error());
EXPECT(result.has_results());
EXPECT_EQ(result.results().size(), 25u);
for (auto& row : result.results()) {
LibSQL+SQLServer: Implement first cut of SELECT ... ORDER BY foo Ordering is done by replacing the straight Vector holding the query result in the SQLResult object with a dedicated Vector subclass that inserts result rows according to their sort key using a binary search. This is done in the ResultSet class. There are limitations: - "SELECT ... ORDER BY 1" (or 2 or 3 etc) is supposed to sort by the n-th result column. This doesn't work yet - "SELECT ... column-expression alias ... ORDER BY alias" is supposed to sort by the column with the given alias. This doesn't work yet What does work however is something like ```SELECT foo FROM bar SORT BY quux``` i.e. sorted by a column not in the result set. Once functions are supported it should be possible to sort by random functions.
2022-01-12 09:49:43 -05:00
EXPECT(row.row.size() == 4);
EXPECT(row.row[1].to_int().value() >= 42);
EXPECT(row.row[1].to_int().value() <= 46);
EXPECT(row.row[3].to_int().value() >= 40);
EXPECT(row.row[3].to_int().value() <= 48);
LibSQL: Implement table joins This patch introduces table joins. It uses a pretty dumb algorithm- starting with a singleton '__unity__' row consisting of a single boolean value, a cartesian product of all tables in the 'FROM' clause is built. This cartesian product is then filtered through the 'WHERE' clause, again without any smarts just using brute force. This patch required a bunch of busy work to allow for example the ColumnNameExpression having to deal with multiple tables potentially having columns with the same name.
2021-11-02 16:49:54 -04:00
}
}
TEST_CASE(select_inner_join)
{
ScopeGuard guard([]() { unlink(db_name); });
auto database = SQL::Database::construct(db_name);
LibSQL: Improve error handling The handling of filesystem level errors was basically non-existing or consisting of `VERIFY_NOT_REACHED` assertions. Addressed this by * Adding `open` methods to `Heap` and `Database` which return errors. * Changing the interface of methods of these classes and clients downstream to propagate these errors. The constructors of `Heap` and `Database` don't open the underlying filesystem file anymore. The SQL statement handlers return an `SQLErrorCode::InternalError` error code if an error comes back from the lower levels. Note that some of these errors are things like duplicate index entry errors that should be caught before the SQL layer attempts to actually update the database. Added tests to catch attempts to open weird or non-existent files as databases. Finally, in between me writing this patch and submitting the PR the AK::Result<Foo, Bar> template got deprecated in favour of ErrorOr<Foo>. This resulted in more busywork.
2021-11-05 19:05:59 -04:00
EXPECT(!database->open().is_error());
LibSQL: Implement table joins This patch introduces table joins. It uses a pretty dumb algorithm- starting with a singleton '__unity__' row consisting of a single boolean value, a cartesian product of all tables in the 'FROM' clause is built. This cartesian product is then filtered through the 'WHERE' clause, again without any smarts just using brute force. This patch required a bunch of busy work to allow for example the ColumnNameExpression having to deal with multiple tables potentially having columns with the same name.
2021-11-02 16:49:54 -04:00
create_two_tables(database);
auto result = execute(database,
"INSERT INTO TestSchema.TestTable1 ( TextColumn1, IntColumn ) VALUES "
"( 'Test_1', 42 ), "
"( 'Test_2', 43 ), "
"( 'Test_3', 44 ), "
"( 'Test_4', 45 ), "
"( 'Test_5', 46 );");
LibSQL+SQLServer: Return the new Result class from statement executions We can now TRY anything that returns a SQL::Result or an AK::Error.
2022-02-09 15:57:57 -05:00
EXPECT(!result.is_error());
EXPECT(result.inserted() == 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: Return the new Result class from statement executions We can now TRY anything that returns a SQL::Result or an AK::Error.
2022-02-09 15:57:57 -05:00
EXPECT(!result.is_error());
EXPECT(result.inserted() == 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: Return the new Result class from statement executions We can now TRY anything that returns a SQL::Result or an AK::Error.
2022-02-09 15:57:57 -05:00
EXPECT(!result.is_error());
EXPECT(result.has_results());
EXPECT_EQ(result.results().size(), 1u);
auto& row = result.results()[0];
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_EQ(row.row.size(), 3u);
EXPECT_EQ(row.row[0].to_int().value(), 42);
EXPECT_EQ(row.row[1].to_string(), "Test_1");
EXPECT_EQ(row.row[2].to_string(), "Test_12");
LibSQL: Implement table joins This patch introduces table joins. It uses a pretty dumb algorithm- starting with a singleton '__unity__' row consisting of a single boolean value, a cartesian product of all tables in the 'FROM' clause is built. This cartesian product is then filtered through the 'WHERE' clause, again without any smarts just using brute force. This patch required a bunch of busy work to allow for example the ColumnNameExpression having to deal with multiple tables potentially having columns with the same name.
2021-11-02 16:49:54 -04:00
}
LibSQL: Implement LIKE SQL expressions
2021-12-29 11:47:29 -03:00
TEST_CASE(select_with_like)
{
ScopeGuard guard([]() { unlink(db_name); });
auto database = SQL::Database::construct(db_name);
EXPECT(!database->open().is_error());
create_table(database);
auto result = execute(database,
"INSERT INTO TestSchema.TestTable ( TextColumn, IntColumn ) VALUES "
"( 'Test+1', 42 ), "
"( 'Test+2', 43 ), "
"( 'Test+3', 44 ), "
"( 'Test+4', 45 ), "
"( 'Test+5', 46 ), "
"( 'Another+Test_6', 47 );");
LibSQL+SQLServer: Return the new Result class from statement executions We can now TRY anything that returns a SQL::Result or an AK::Error.
2022-02-09 15:57:57 -05:00
EXPECT(!result.is_error());
EXPECT(result.inserted() == 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: Return the new Result class from statement executions We can now TRY anything that returns a SQL::Result or an AK::Error.
2022-02-09 15:57:57 -05:00
EXPECT(!result.is_error());
EXPECT(result.has_results());
EXPECT_EQ(result.results().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: Return the new Result class from statement executions We can now TRY anything that returns a SQL::Result or an AK::Error.
2022-02-09 15:57:57 -05:00
EXPECT(!result.is_error());
EXPECT(result.has_results());
EXPECT_EQ(result.results().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: Return the new Result class from statement executions We can now TRY anything that returns a SQL::Result or an AK::Error.
2022-02-09 15:57:57 -05:00
EXPECT(!result.is_error());
EXPECT(result.has_results());
EXPECT_EQ(result.results().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: Return the new Result class from statement executions We can now TRY anything that returns a SQL::Result or an AK::Error.
2022-02-09 15:57:57 -05:00
EXPECT(!result.is_error());
EXPECT(result.has_results());
EXPECT_EQ(result.results().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: Return the new Result class from statement executions We can now TRY anything that returns a SQL::Result or an AK::Error.
2022-02-09 15:57:57 -05:00
EXPECT(!result.is_error());
EXPECT(result.has_results());
EXPECT_EQ(result.results().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: Return the new Result class from statement executions We can now TRY anything that returns a SQL::Result or an AK::Error.
2022-02-09 15:57:57 -05:00
EXPECT(!result.is_error());
EXPECT(result.has_results());
EXPECT_EQ(result.results().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: Return the new Result class from statement executions We can now TRY anything that returns a SQL::Result or an AK::Error.
2022-02-09 15:57:57 -05:00
EXPECT(!result.is_error());
EXPECT(result.has_results());
EXPECT_EQ(result.results().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
result = execute(database, "SELECT TextColumn FROM TestSchema.TestTable WHERE TextColumn LIKE '%' ESCAPE '';");
LibSQL+SQLServer: Return the new Result class from statement executions We can now TRY anything that returns a SQL::Result or an AK::Error.
2022-02-09 15:57:57 -05:00
EXPECT(result.error() == SQL::SQLErrorCode::SyntaxError);
EXPECT(!result.has_results());
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
result = execute(database, "SELECT TextColumn FROM TestSchema.TestTable WHERE TextColumn LIKE '%' ESCAPE 'whf';");
LibSQL+SQLServer: Return the new Result class from statement executions We can now TRY anything that returns a SQL::Result or an AK::Error.
2022-02-09 15:57:57 -05:00
EXPECT(result.error() == SQL::SQLErrorCode::SyntaxError);
EXPECT(!result.has_results());
LibSQL: Implement LIKE SQL expressions
2021-12-29 11:47:29 -03:00
}
LibSQL+SQLServer: Implement first cut of SELECT ... ORDER BY foo Ordering is done by replacing the straight Vector holding the query result in the SQLResult object with a dedicated Vector subclass that inserts result rows according to their sort key using a binary search. This is done in the ResultSet class. There are limitations: - "SELECT ... ORDER BY 1" (or 2 or 3 etc) is supposed to sort by the n-th result column. This doesn't work yet - "SELECT ... column-expression alias ... ORDER BY alias" is supposed to sort by the column with the given alias. This doesn't work yet What does work however is something like ```SELECT foo FROM bar SORT BY quux``` i.e. sorted by a column not in the result set. Once functions are supported it should be possible to sort by random functions.
2022-01-12 09:49:43 -05:00
TEST_CASE(select_with_order)
{
ScopeGuard guard([]() { unlink(db_name); });
auto database = SQL::Database::construct(db_name);
EXPECT(!database->open().is_error());
create_table(database);
auto result = execute(database,
"INSERT INTO TestSchema.TestTable ( TextColumn, IntColumn ) VALUES "
"( 'Test_5', 44 ), "
"( 'Test_2', 42 ), "
"( 'Test_1', 47 ), "
"( 'Test_3', 40 ), "
"( 'Test_4', 41 );");
LibSQL+SQLServer: Return the new Result class from statement executions We can now TRY anything that returns a SQL::Result or an AK::Error.
2022-02-09 15:57:57 -05:00
EXPECT(!result.is_error());
EXPECT(result.inserted() == 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: Return the new Result class from statement executions We can now TRY anything that returns a SQL::Result or an AK::Error.
2022-02-09 15:57:57 -05:00
EXPECT(!result.is_error());
EXPECT(result.has_results());
auto rows = result.results();
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_EQ(rows.size(), 5u);
EXPECT_EQ(rows[0].row[1].to_int().value(), 40);
EXPECT_EQ(rows[1].row[1].to_int().value(), 41);
EXPECT_EQ(rows[2].row[1].to_int().value(), 42);
EXPECT_EQ(rows[3].row[1].to_int().value(), 44);
EXPECT_EQ(rows[4].row[1].to_int().value(), 47);
result = execute(database, "SELECT TextColumn, IntColumn FROM TestSchema.TestTable ORDER BY TextColumn;");
LibSQL+SQLServer: Return the new Result class from statement executions We can now TRY anything that returns a SQL::Result or an AK::Error.
2022-02-09 15:57:57 -05:00
EXPECT(!result.is_error());
EXPECT(result.has_results());
rows = result.results();
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_EQ(rows.size(), 5u);
EXPECT_EQ(rows[0].row[0].to_string(), "Test_1");
EXPECT_EQ(rows[1].row[0].to_string(), "Test_2");
EXPECT_EQ(rows[2].row[0].to_string(), "Test_3");
EXPECT_EQ(rows[3].row[0].to_string(), "Test_4");
EXPECT_EQ(rows[4].row[0].to_string(), "Test_5");
}
LibSQL: Add simple REGEXP match The implementation of LIKE uses regexes under the hood, and this implementation of REGEXP takes the same approach. It employs PosixExtended from LibRegex with case insensitive and Unicode flags set. The implementation of LIKE is based on SQLlite specs, but SQLlite does not offer directions for a built-in regex functionality, so this one uses LibRegex.
2022-01-22 15:43:30 +01:00
TEST_CASE(select_with_regexp)
{
ScopeGuard guard([]() { unlink(db_name); });
auto database = SQL::Database::construct(db_name);
EXPECT(!database->open().is_error());
create_table(database);
auto result = execute(database,
"INSERT INTO TestSchema.TestTable ( TextColumn, IntColumn ) VALUES "
"( 'Test+1', 42 ), "
"( 'Pröv+2', 43 ), "
"( 'Test(3)', 44 ), "
"( 'Test[4]', 45 ), "
"( 'Test+5', 46 ), "
"( 'Another-Test_6', 47 );");
LibSQL+SQLServer: Return the new Result class from statement executions We can now TRY anything that returns a SQL::Result or an AK::Error.
2022-02-09 15:57:57 -05:00
EXPECT(!result.is_error());
EXPECT(result.inserted() == 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: Return the new Result class from statement executions We can now TRY anything that returns a SQL::Result or an AK::Error.
2022-02-09 15:57:57 -05:00
EXPECT(!result.is_error());
EXPECT(result.has_results());
EXPECT_EQ(result.results().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: Return the new Result class from statement executions We can now TRY anything that returns a SQL::Result or an AK::Error.
2022-02-09 15:57:57 -05:00
EXPECT(!result.is_error());
EXPECT(result.has_results());
EXPECT_EQ(result.results().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: Return the new Result class from statement executions We can now TRY anything that returns a SQL::Result or an AK::Error.
2022-02-09 15:57:57 -05:00
EXPECT(!result.is_error());
EXPECT(result.has_results());
EXPECT_EQ(result.results().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: Return the new Result class from statement executions We can now TRY anything that returns a SQL::Result or an AK::Error.
2022-02-09 15:57:57 -05:00
EXPECT(!result.is_error());
EXPECT(result.has_results());
EXPECT_EQ(result.results().size(), 1u);
LibSQL: Add simple REGEXP match The implementation of LIKE uses regexes under the hood, and this implementation of REGEXP takes the same approach. It employs PosixExtended from LibRegex with case insensitive and Unicode flags set. The implementation of LIKE is based on SQLlite specs, but SQLlite does not offer directions for a built-in regex functionality, so this one uses LibRegex.
2022-01-22 15:43:30 +01:00
}
TEST_CASE(handle_regexp_errors)
{
ScopeGuard guard([]() { unlink(db_name); });
auto database = SQL::Database::construct(db_name);
EXPECT(!database->open().is_error());
create_table(database);
auto result = execute(database,
"INSERT INTO TestSchema.TestTable ( TextColumn, IntColumn ) VALUES "
"( 'Test', 0 );");
LibSQL+SQLServer: Return the new Result class from statement executions We can now TRY anything that returns a SQL::Result or an AK::Error.
2022-02-09 15:57:57 -05:00
EXPECT(!result.is_error());
EXPECT(result.inserted() == 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
result = execute(database, "SELECT TextColumn FROM TestSchema.TestTable WHERE TextColumn REGEXP 'Test\\+[0-9.*';");
LibSQL+SQLServer: Return the new Result class from statement executions We can now TRY anything that returns a SQL::Result or an AK::Error.
2022-02-09 15:57:57 -05:00
EXPECT(result.is_error());
EXPECT(!result.has_results());
LibSQL: Add simple REGEXP match The implementation of LIKE uses regexes under the hood, and this implementation of REGEXP takes the same approach. It employs PosixExtended from LibRegex with case insensitive and Unicode flags set. The implementation of LIKE is based on SQLlite specs, but SQLlite does not offer directions for a built-in regex functionality, so this one uses LibRegex.
2022-01-22 15:43:30 +01:00
}
LibSQL+SQLServer: Implement first cut of SELECT ... ORDER BY foo Ordering is done by replacing the straight Vector holding the query result in the SQLResult object with a dedicated Vector subclass that inserts result rows according to their sort key using a binary search. This is done in the ResultSet class. There are limitations: - "SELECT ... ORDER BY 1" (or 2 or 3 etc) is supposed to sort by the n-th result column. This doesn't work yet - "SELECT ... column-expression alias ... ORDER BY alias" is supposed to sort by the column with the given alias. This doesn't work yet What does work however is something like ```SELECT foo FROM bar SORT BY quux``` i.e. sorted by a column not in the result set. Once functions are supported it should be possible to sort by random functions.
2022-01-12 09:49:43 -05:00
TEST_CASE(select_with_order_two_columns)
{
ScopeGuard guard([]() { unlink(db_name); });
auto database = SQL::Database::construct(db_name);
EXPECT(!database->open().is_error());
create_table(database);
auto result = execute(database,
"INSERT INTO TestSchema.TestTable ( TextColumn, IntColumn ) VALUES "
"( 'Test_5', 44 ), "
"( 'Test_2', 42 ), "
"( 'Test_1', 47 ), "
"( 'Test_2', 40 ), "
"( 'Test_4', 41 );");
LibSQL+SQLServer: Return the new Result class from statement executions We can now TRY anything that returns a SQL::Result or an AK::Error.
2022-02-09 15:57:57 -05:00
EXPECT(!result.is_error());
EXPECT(result.inserted() == 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: Return the new Result class from statement executions We can now TRY anything that returns a SQL::Result or an AK::Error.
2022-02-09 15:57:57 -05:00
EXPECT(!result.is_error());
EXPECT(result.has_results());
auto rows = result.results();
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_EQ(rows.size(), 5u);
EXPECT_EQ(rows[0].row[0].to_string(), "Test_1");
EXPECT_EQ(rows[0].row[1].to_int().value(), 47);
EXPECT_EQ(rows[1].row[0].to_string(), "Test_2");
EXPECT_EQ(rows[1].row[1].to_int().value(), 40);
EXPECT_EQ(rows[2].row[0].to_string(), "Test_2");
EXPECT_EQ(rows[2].row[1].to_int().value(), 42);
EXPECT_EQ(rows[3].row[0].to_string(), "Test_4");
EXPECT_EQ(rows[3].row[1].to_int().value(), 41);
EXPECT_EQ(rows[4].row[0].to_string(), "Test_5");
EXPECT_EQ(rows[4].row[1].to_int().value(), 44);
}
TEST_CASE(select_with_order_by_column_not_in_result)
{
ScopeGuard guard([]() { unlink(db_name); });
auto database = SQL::Database::construct(db_name);
EXPECT(!database->open().is_error());
create_table(database);
auto result = execute(database,
"INSERT INTO TestSchema.TestTable ( TextColumn, IntColumn ) VALUES "
"( 'Test_5', 44 ), "
"( 'Test_2', 42 ), "
"( 'Test_1', 47 ), "
"( 'Test_3', 40 ), "
"( 'Test_4', 41 );");
LibSQL+SQLServer: Return the new Result class from statement executions We can now TRY anything that returns a SQL::Result or an AK::Error.
2022-02-09 15:57:57 -05:00
EXPECT(!result.is_error());
EXPECT(result.inserted() == 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: Return the new Result class from statement executions We can now TRY anything that returns a SQL::Result or an AK::Error.
2022-02-09 15:57:57 -05:00
EXPECT(!result.is_error());
EXPECT(result.has_results());
auto rows = result.results();
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_EQ(rows.size(), 5u);
EXPECT_EQ(rows[0].row[0].to_string(), "Test_3");
EXPECT_EQ(rows[1].row[0].to_string(), "Test_4");
EXPECT_EQ(rows[2].row[0].to_string(), "Test_2");
EXPECT_EQ(rows[3].row[0].to_string(), "Test_5");
EXPECT_EQ(rows[4].row[0].to_string(), "Test_1");
}
LibSQL: Introduce SELECT ... LIMIT xxx OFFSET yyy What it says on the tin.
2022-01-12 11:41:58 -05:00
TEST_CASE(select_with_limit)
{
ScopeGuard guard([]() { unlink(db_name); });
auto database = SQL::Database::construct(db_name);
EXPECT(!database->open().is_error());
create_table(database);
for (auto count = 0; count < 100; count++) {
auto result = execute(database,
String::formatted("INSERT INTO TestSchema.TestTable ( TextColumn, IntColumn ) VALUES ( 'Test_{}', {} );", count, count));
LibSQL+SQLServer: Return the new Result class from statement executions We can now TRY anything that returns a SQL::Result or an AK::Error.
2022-02-09 15:57:57 -05:00
EXPECT(!result.is_error());
EXPECT(result.inserted() == 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: Return the new Result class from statement executions We can now TRY anything that returns a SQL::Result or an AK::Error.
2022-02-09 15:57:57 -05:00
EXPECT(!result.is_error());
EXPECT(result.has_results());
auto rows = result.results();
LibSQL: Introduce SELECT ... LIMIT xxx OFFSET yyy What it says on the tin.
2022-01-12 11:41:58 -05:00
EXPECT_EQ(rows.size(), 10u);
}
TEST_CASE(select_with_limit_and_offset)
{
ScopeGuard guard([]() { unlink(db_name); });
auto database = SQL::Database::construct(db_name);
EXPECT(!database->open().is_error());
create_table(database);
for (auto count = 0; count < 100; count++) {
auto result = execute(database,
String::formatted("INSERT INTO TestSchema.TestTable ( TextColumn, IntColumn ) VALUES ( 'Test_{}', {} );", count, count));
LibSQL+SQLServer: Return the new Result class from statement executions We can now TRY anything that returns a SQL::Result or an AK::Error.
2022-02-09 15:57:57 -05:00
EXPECT(!result.is_error());
EXPECT(result.inserted() == 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: Return the new Result class from statement executions We can now TRY anything that returns a SQL::Result or an AK::Error.
2022-02-09 15:57:57 -05:00
EXPECT(!result.is_error());
EXPECT(result.has_results());
auto rows = result.results();
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_order_limit_and_offset)
{
ScopeGuard guard([]() { unlink(db_name); });
auto database = SQL::Database::construct(db_name);
EXPECT(!database->open().is_error());
create_table(database);
for (auto count = 0; count < 100; count++) {
auto result = execute(database,
String::formatted("INSERT INTO TestSchema.TestTable ( TextColumn, IntColumn ) VALUES ( 'Test_{}', {} );", count, count));
LibSQL+SQLServer: Return the new Result class from statement executions We can now TRY anything that returns a SQL::Result or an AK::Error.
2022-02-09 15:57:57 -05:00
EXPECT(!result.is_error());
EXPECT(result.inserted() == 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: Return the new Result class from statement executions We can now TRY anything that returns a SQL::Result or an AK::Error.
2022-02-09 15:57:57 -05:00
EXPECT(!result.is_error());
EXPECT(result.has_results());
auto rows = result.results();
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);
EXPECT_EQ(rows[0].row[1].to_int().value(), 10);
EXPECT_EQ(rows[1].row[1].to_int().value(), 11);
EXPECT_EQ(rows[2].row[1].to_int().value(), 12);
EXPECT_EQ(rows[3].row[1].to_int().value(), 13);
EXPECT_EQ(rows[4].row[1].to_int().value(), 14);
EXPECT_EQ(rows[5].row[1].to_int().value(), 15);
EXPECT_EQ(rows[6].row[1].to_int().value(), 16);
EXPECT_EQ(rows[7].row[1].to_int().value(), 17);
EXPECT_EQ(rows[8].row[1].to_int().value(), 18);
EXPECT_EQ(rows[9].row[1].to_int().value(), 19);
}
TEST_CASE(select_with_limit_out_of_bounds)
{
ScopeGuard guard([]() { unlink(db_name); });
auto database = SQL::Database::construct(db_name);
EXPECT(!database->open().is_error());
create_table(database);
for (auto count = 0; count < 100; count++) {
auto result = execute(database,
String::formatted("INSERT INTO TestSchema.TestTable ( TextColumn, IntColumn ) VALUES ( 'Test_{}', {} );", count, count));
LibSQL+SQLServer: Return the new Result class from statement executions We can now TRY anything that returns a SQL::Result or an AK::Error.
2022-02-09 15:57:57 -05:00
EXPECT(!result.is_error());
EXPECT(result.inserted() == 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: Return the new Result class from statement executions We can now TRY anything that returns a SQL::Result or an AK::Error.
2022-02-09 15:57:57 -05:00
EXPECT(!result.is_error());
EXPECT(result.has_results());
auto rows = result.results();
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(), 100u);
}
TEST_CASE(select_with_offset_out_of_bounds)
{
ScopeGuard guard([]() { unlink(db_name); });
auto database = SQL::Database::construct(db_name);
EXPECT(!database->open().is_error());
create_table(database);
for (auto count = 0; count < 100; count++) {
auto result = execute(database,
String::formatted("INSERT INTO TestSchema.TestTable ( TextColumn, IntColumn ) VALUES ( 'Test_{}', {} );", count, count));
LibSQL+SQLServer: Return the new Result class from statement executions We can now TRY anything that returns a SQL::Result or an AK::Error.
2022-02-09 15:57:57 -05:00
EXPECT(!result.is_error());
EXPECT(result.inserted() == 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: Return the new Result class from statement executions We can now TRY anything that returns a SQL::Result or an AK::Error.
2022-02-09 15:57:57 -05:00
EXPECT(!result.is_error());
EXPECT(result.has_results());
auto rows = result.results();
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(), 0u);
}
LibSQL: Implement DESCRIBE TABLE tests
2021-09-19 21:35:16 +02:00
TEST_CASE(describe_table)
{
ScopeGuard guard([]() { unlink(db_name); });
auto database = SQL::Database::construct(db_name);
EXPECT(!database->open().is_error());
create_table(database);
auto result = execute(database, "DESCRIBE TABLE TestSchema.TestTable;");
LibSQL+SQLServer: Return the new Result class from statement executions We can now TRY anything that returns a SQL::Result or an AK::Error.
2022-02-09 15:57:57 -05:00
EXPECT(!result.is_error());
EXPECT(result.has_results());
EXPECT_EQ(result.results().size(), 2u);
LibSQL: Implement DESCRIBE TABLE tests
2021-09-19 21:35:16 +02:00
LibSQL+SQLServer: Return the new Result class from statement executions We can now TRY anything that returns a SQL::Result or an AK::Error.
2022-02-09 15:57:57 -05:00
auto rows = result.results();
LibSQL: Implement DESCRIBE TABLE tests
2021-09-19 21:35:16 +02:00
auto& row1 = rows[0];
EXPECT_EQ(row1.row[0].to_string(), "TEXTCOLUMN");
EXPECT_EQ(row1.row[1].to_string(), "text");
auto& row2 = rows[1];
EXPECT_EQ(row2.row[0].to_string(), "INTCOLUMN");
EXPECT_EQ(row2.row[1].to_string(), "int");
}
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