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

213 lines
8 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>
*
* SPDX-License-Identifier: BSD-2-Clause
*/
#include <unistd.h>
#include <AK/ScopeGuard.h>
#include <LibSQL/AST/Parser.h>
#include <LibSQL/Database.h>
#include <LibSQL/Row.h>
#include <LibSQL/SQLResult.h>
#include <LibSQL/Value.h>
#include <LibTest/TestCase.h>
namespace {
constexpr const char* db_name = "/tmp/test.db";
RefPtr<SQL::SQLResult> execute(NonnullRefPtr<SQL::Database> database, String const& sql)
{
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 Tests: Add tests for `SELECT ... WHERE ...`
2021-10-23 10:47:12 -04:00
if (result->error().code != SQL::SQLErrorCode::NoError)
outln("{}", result->error().to_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: Check NoError individually in execution tests This enables tests to check that a statement is erroneous, we could not do so by only calling `execute()` since it asserted that no errors occurred.
2021-09-17 20:35:55 +02:00
EXPECT(result->error().code == SQL::SQLErrorCode::NoError);
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(result->inserted() == 1);
}
void create_table(NonnullRefPtr<SQL::Database> database)
{
create_schema(database);
auto result = execute(database, "CREATE TABLE TestSchema.TestTable ( TextColumn text, IntColumn integer );");
LibSQL: Check NoError individually in execution tests This enables tests to check that a statement is erroneous, we could not do so by only calling `execute()` since it asserted that no errors occurred.
2021-09-17 20:35:55 +02:00
EXPECT(result->error().code == SQL::SQLErrorCode::NoError);
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(result->inserted() == 1);
}
TEST_CASE(create_schema)
{
ScopeGuard guard([]() { unlink(db_name); });
auto database = SQL::Database::construct(db_name);
create_schema(database);
auto schema = database->get_schema("TESTSCHEMA");
EXPECT(schema);
}
TEST_CASE(create_table)
{
ScopeGuard guard([]() { unlink(db_name); });
auto database = SQL::Database::construct(db_name);
create_table(database);
auto table = database->get_table("TESTSCHEMA", "TESTTABLE");
EXPECT(table);
}
TEST_CASE(insert_into_table)
{
ScopeGuard guard([]() { unlink(db_name); });
auto database = SQL::Database::construct(db_name);
create_table(database);
auto result = execute(database, "INSERT INTO TestSchema.TestTable ( TextColumn, IntColumn ) VALUES ( 'Test', 42 );");
LibSQL: Check NoError individually in execution tests This enables tests to check that a statement is erroneous, we could not do so by only calling `execute()` since it asserted that no errors occurred.
2021-09-17 20:35:55 +02:00
EXPECT(result->error().code == SQL::SQLErrorCode::NoError);
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(result->inserted() == 1);
auto table = database->get_table("TESTSCHEMA", "TESTTABLE");
int count = 0;
for (auto& row : database->select_all(*table)) {
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);
create_table(database);
auto result = execute(database, "INSERT INTO TestSchema.TestTable ( TextColumn, IntColumn ) VALUES (43, 'Test_2');");
EXPECT(result->inserted() == 0);
EXPECT(result->error().code == SQL::SQLErrorCode::InvalidValueType);
}
TEST_CASE(insert_into_table_multiple_tuples_wrong_data_types)
{
ScopeGuard guard([]() { unlink(db_name); });
auto database = SQL::Database::construct(db_name);
create_table(database);
auto result = execute(database, "INSERT INTO TestSchema.TestTable ( TextColumn, IntColumn ) VALUES ('Test_1', 42), (43, 'Test_2');");
EXPECT(result->inserted() == 0);
EXPECT(result->error().code == SQL::SQLErrorCode::InvalidValueType);
}
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);
create_table(database);
auto result = execute(database, "INSERT INTO TestSchema.TestTable VALUES ( 42 );");
EXPECT(result->error().code == SQL::SQLErrorCode::InvalidNumberOfValues);
EXPECT(result->inserted() == 0);
}
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);
create_table(database);
auto result = execute(database, "INSERT INTO TestSchema.TestTable VALUES ('Test_1', 42), ('Test_2', 43);");
EXPECT(result->error().code == SQL::SQLErrorCode::NoError);
EXPECT(result->inserted() == 2);
auto table = database->get_table("TESTSCHEMA", "TESTTABLE");
EXPECT_EQ(database->select_all(*table).size(), 2u);
}
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);
create_table(database);
auto result = execute(database, "INSERT INTO TestSchema.TestTable ( TextColumn, IntColumn ) VALUES ( 'Test_1', 42 ), ( 'Test_2', 43 );");
LibSQL: Check NoError individually in execution tests This enables tests to check that a statement is erroneous, we could not do so by only calling `execute()` since it asserted that no errors occurred.
2021-09-17 20:35:55 +02:00
EXPECT(result->error().code == SQL::SQLErrorCode::NoError);
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(result->inserted() == 2);
result = execute(database, "INSERT INTO TestSchema.TestTable ( TextColumn, IntColumn ) VALUES ( 'Test_3', 44 ), ( 'Test_4', 45 );");
LibSQL: Check NoError individually in execution tests This enables tests to check that a statement is erroneous, we could not do so by only calling `execute()` since it asserted that no errors occurred.
2021-09-17 20:35:55 +02:00
EXPECT(result->error().code == SQL::SQLErrorCode::NoError);
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(result->inserted() == 2);
result = execute(database, "INSERT INTO TestSchema.TestTable ( TextColumn, IntColumn ) VALUES ( 'Test_5', 46 );");
LibSQL: Check NoError individually in execution tests This enables tests to check that a statement is erroneous, we could not do so by only calling `execute()` since it asserted that no errors occurred.
2021-09-17 20:35:55 +02:00
EXPECT(result->error().code == SQL::SQLErrorCode::NoError);
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(result->inserted() == 1);
result = execute(database, "SELECT * FROM TestSchema.TestTable;");
LibSQL: Check NoError individually in execution tests This enables tests to check that a statement is erroneous, we could not do so by only calling `execute()` since it asserted that no errors occurred.
2021-09-17 20:35:55 +02:00
EXPECT(result->error().code == SQL::SQLErrorCode::NoError);
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(result->has_results());
EXPECT_EQ(result->results().size(), 5u);
}
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);
create_table(database);
auto result = execute(database, "INSERT INTO TestSchema.TestTable ( TextColumn, IntColumn ) VALUES ( 'Test_1', 42 ), ( 'Test_2', 43 );");
EXPECT(result->error().code == SQL::SQLErrorCode::NoError);
EXPECT(result->inserted() == 2);
result = execute(database, "INSERT INTO TestSchema.TestTable ( TextColumn, IntColumn ) VALUES ( 'Test_3', 44 ), ( 'Test_4', 45 );");
EXPECT(result->error().code == SQL::SQLErrorCode::NoError);
EXPECT(result->inserted() == 2);
result = execute(database, "INSERT INTO TestSchema.TestTable ( TextColumn, IntColumn ) VALUES ( 'Test_5', 46 );");
EXPECT(result->error().code == SQL::SQLErrorCode::NoError);
EXPECT(result->inserted() == 1);
result = execute(database, "SELECT TextColumn FROM TestSchema.TestTable;");
EXPECT(result->error().code == SQL::SQLErrorCode::NoError);
EXPECT(result->has_results());
EXPECT_EQ(result->results().size(), 5u);
EXPECT_EQ(result->results()[0].size(), 1u);
}
TEST_CASE(select_with_nonexisting_column_name)
{
ScopeGuard guard([]() { unlink(db_name); });
auto database = SQL::Database::construct(db_name);
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 );");
EXPECT(result->error().code == SQL::SQLErrorCode::NoError);
EXPECT(result->inserted() == 5);
result = execute(database, "SELECT Bogus FROM TestSchema.TestTable;");
EXPECT(result->error().code == SQL::SQLErrorCode::ColumnDoesNotExist);
}
TEST_CASE(select_with_where)
{
ScopeGuard guard([]() { unlink(db_name); });
auto database = SQL::Database::construct(db_name);
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 );");
EXPECT(result->error().code == SQL::SQLErrorCode::NoError);
EXPECT(result->inserted() == 5);
result = execute(database, "SELECT TextColumn, IntColumn FROM TestSchema.TestTable WHERE IntColumn > 44;");
EXPECT(result->error().code == SQL::SQLErrorCode::NoError);
EXPECT(result->has_results());
EXPECT_EQ(result->results().size(), 2u);
for (auto& row : result->results()) {
EXPECT(row[1].to_int().value() > 44);
}
}
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