2021-06-17 13:23:52 -04:00
|
|
|
/*
|
|
|
|
* Copyright (c) 2021, Jan de Visser <jan@de-visser.net>
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
* Copyright (c) 2022, Tim Flynn <trflynn89@serenityos.org>
|
2021-06-17 13:23:52 -04:00
|
|
|
*
|
|
|
|
* SPDX-License-Identifier: BSD-2-Clause
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <unistd.h>
|
|
|
|
|
|
|
|
#include <LibSQL/Meta.h>
|
|
|
|
#include <LibSQL/Row.h>
|
|
|
|
#include <LibSQL/Tuple.h>
|
|
|
|
#include <LibSQL/Value.h>
|
|
|
|
#include <LibTest/TestCase.h>
|
|
|
|
|
2021-07-17 07:02:28 -04:00
|
|
|
TEST_CASE(null_value)
|
2021-06-17 13:23:52 -04:00
|
|
|
{
|
2021-07-17 07:02:28 -04:00
|
|
|
SQL::Value v(SQL::SQLType::Null);
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
EXPECT_EQ(v.type(), SQL::SQLType::Null);
|
2022-12-06 01:12:49 +00:00
|
|
|
EXPECT_EQ(v.to_deprecated_string(), "(null)"sv);
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
EXPECT(!v.to_bool().has_value());
|
|
|
|
EXPECT(!v.to_int().has_value());
|
|
|
|
EXPECT(!v.to_u32().has_value());
|
|
|
|
EXPECT(!v.to_double().has_value());
|
|
|
|
}
|
|
|
|
|
|
|
|
TEST_CASE(assign_null)
|
|
|
|
{
|
|
|
|
SQL::Value v("Test");
|
|
|
|
EXPECT_EQ(v.type(), SQL::SQLType::Text);
|
|
|
|
EXPECT(!v.is_null());
|
|
|
|
|
|
|
|
v = SQL::Value();
|
|
|
|
EXPECT_EQ(v.type(), SQL::SQLType::Null);
|
2021-07-17 07:02:28 -04:00
|
|
|
EXPECT(v.is_null());
|
2021-06-17 13:23:52 -04:00
|
|
|
}
|
|
|
|
|
2021-07-17 07:02:28 -04:00
|
|
|
TEST_CASE(text_value)
|
2021-06-17 13:23:52 -04:00
|
|
|
{
|
2021-07-17 07:02:28 -04:00
|
|
|
{
|
|
|
|
SQL::Value v(SQL::SQLType::Text);
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
EXPECT_EQ(v.type(), SQL::SQLType::Text);
|
2021-07-17 07:02:28 -04:00
|
|
|
EXPECT(v.is_null());
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
|
|
|
|
v = "Test"sv;
|
|
|
|
EXPECT_EQ(v.type(), SQL::SQLType::Text);
|
2022-12-06 01:12:49 +00:00
|
|
|
EXPECT_EQ(v.to_deprecated_string(), "Test"sv);
|
2021-07-17 07:02:28 -04:00
|
|
|
}
|
|
|
|
{
|
2022-12-04 18:02:33 +00:00
|
|
|
SQL::Value v(DeprecatedString("String Test"sv));
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
EXPECT_EQ(v.type(), SQL::SQLType::Text);
|
2022-12-06 01:12:49 +00:00
|
|
|
EXPECT_EQ(v.to_deprecated_string(), "String Test"sv);
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
|
2022-12-04 18:02:33 +00:00
|
|
|
v = DeprecatedString("String Test 2"sv);
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
EXPECT_EQ(v.type(), SQL::SQLType::Text);
|
2022-12-06 01:12:49 +00:00
|
|
|
EXPECT_EQ(v.to_deprecated_string(), "String Test 2"sv);
|
2021-07-17 07:02:28 -04:00
|
|
|
}
|
|
|
|
{
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
SQL::Value v("const char * Test");
|
|
|
|
EXPECT_EQ(v.type(), SQL::SQLType::Text);
|
2022-12-06 01:12:49 +00:00
|
|
|
EXPECT_EQ(v.to_deprecated_string(), "const char * Test"sv);
|
2021-07-17 07:02:28 -04:00
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
v = "const char * Test 2";
|
|
|
|
EXPECT_EQ(v.type(), SQL::SQLType::Text);
|
2022-12-06 01:12:49 +00:00
|
|
|
EXPECT_EQ(v.to_deprecated_string(), "const char * Test 2"sv);
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
}
|
2021-07-17 07:02:28 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
TEST_CASE(text_value_to_other_types)
|
|
|
|
{
|
|
|
|
{
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
SQL::Value v("42");
|
|
|
|
EXPECT_EQ(v.type(), SQL::SQLType::Text);
|
|
|
|
|
2021-07-17 07:02:28 -04:00
|
|
|
EXPECT(v.to_int().has_value());
|
|
|
|
EXPECT_EQ(v.to_int().value(), 42);
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
|
2021-07-17 07:02:28 -04:00
|
|
|
EXPECT(v.to_double().has_value());
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
EXPECT((v.to_double().value() - 42.0) < NumericLimits<double>().epsilon());
|
2021-07-17 07:02:28 -04:00
|
|
|
}
|
|
|
|
{
|
|
|
|
SQL::Value v("true");
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
EXPECT_EQ(v.type(), SQL::SQLType::Text);
|
|
|
|
|
2021-07-17 07:02:28 -04:00
|
|
|
EXPECT(v.to_bool().has_value());
|
|
|
|
EXPECT(v.to_bool().value());
|
|
|
|
}
|
|
|
|
{
|
|
|
|
SQL::Value v("false");
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
EXPECT_EQ(v.type(), SQL::SQLType::Text);
|
|
|
|
|
2021-07-17 07:02:28 -04:00
|
|
|
EXPECT(v.to_bool().has_value());
|
|
|
|
EXPECT(!v.to_bool().value());
|
|
|
|
}
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
{
|
|
|
|
SQL::Value v("foo");
|
|
|
|
EXPECT_EQ(v.type(), SQL::SQLType::Text);
|
|
|
|
|
|
|
|
EXPECT(!v.to_bool().has_value());
|
|
|
|
EXPECT(!v.to_int().has_value());
|
|
|
|
EXPECT(!v.to_u32().has_value());
|
|
|
|
EXPECT(!v.to_double().has_value());
|
|
|
|
}
|
|
|
|
{
|
|
|
|
SQL::Value v("3.14");
|
|
|
|
EXPECT_EQ(v.type(), SQL::SQLType::Text);
|
|
|
|
|
|
|
|
EXPECT(v.to_double().has_value());
|
|
|
|
EXPECT((v.to_double().value() - 3.14) < NumericLimits<double>().epsilon());
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
TEST_CASE(assign_int_to_text_value)
|
|
|
|
{
|
|
|
|
SQL::Value v(SQL::SQLType::Text);
|
|
|
|
EXPECT_EQ(v.type(), SQL::SQLType::Text);
|
|
|
|
EXPECT(v.is_null());
|
|
|
|
|
|
|
|
v = 42;
|
|
|
|
EXPECT_EQ(v.type(), SQL::SQLType::Integer);
|
|
|
|
EXPECT_EQ(v, 42);
|
2021-06-17 13:23:52 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
TEST_CASE(serialize_text_value)
|
|
|
|
{
|
2021-07-17 07:02:28 -04:00
|
|
|
SQL::Value v("Test");
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
EXPECT_EQ(v.type(), SQL::SQLType::Text);
|
|
|
|
EXPECT_EQ(v, "Test"sv);
|
2021-06-17 13:23:52 -04:00
|
|
|
|
2021-08-18 20:50:13 -04:00
|
|
|
SQL::Serializer serializer;
|
|
|
|
serializer.serialize<SQL::Value>(v);
|
2021-06-17 13:23:52 -04:00
|
|
|
|
2021-08-18 20:50:13 -04:00
|
|
|
serializer.rewind();
|
|
|
|
auto v2 = serializer.deserialize<SQL::Value>();
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
EXPECT_EQ(v2.type(), SQL::SQLType::Text);
|
|
|
|
EXPECT_EQ(v2, "Test"sv);
|
|
|
|
EXPECT_EQ(v2, v);
|
2021-06-17 13:23:52 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
TEST_CASE(integer_value)
|
|
|
|
{
|
2021-07-17 07:02:28 -04:00
|
|
|
{
|
|
|
|
SQL::Value v(SQL::SQLType::Integer);
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
EXPECT_EQ(v.type(), SQL::SQLType::Integer);
|
2021-07-17 07:02:28 -04:00
|
|
|
EXPECT(v.is_null());
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
|
2021-07-17 07:02:28 -04:00
|
|
|
v = 42;
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
EXPECT_EQ(v.type(), SQL::SQLType::Integer);
|
|
|
|
|
|
|
|
EXPECT(v.to_int().has_value());
|
|
|
|
EXPECT_EQ(v.to_int().value(), 42);
|
2022-12-06 01:12:49 +00:00
|
|
|
EXPECT_EQ(v.to_deprecated_string(), "42"sv);
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
|
2021-07-17 07:02:28 -04:00
|
|
|
EXPECT(v.to_double().has_value());
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
EXPECT((v.to_double().value() - 42.0) < NumericLimits<double>().epsilon());
|
|
|
|
|
2021-07-17 07:02:28 -04:00
|
|
|
EXPECT(v.to_bool().has_value());
|
|
|
|
EXPECT(v.to_bool().value());
|
|
|
|
}
|
|
|
|
{
|
|
|
|
SQL::Value v(0);
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
EXPECT_EQ(v.type(), SQL::SQLType::Integer);
|
|
|
|
|
|
|
|
EXPECT(v.to_int().has_value());
|
|
|
|
EXPECT_EQ(v.to_int().value(), 0);
|
|
|
|
|
2021-07-17 07:02:28 -04:00
|
|
|
EXPECT(v.to_bool().has_value());
|
|
|
|
EXPECT(!v.to_bool().value());
|
|
|
|
}
|
|
|
|
{
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
SQL::Value v(42);
|
|
|
|
EXPECT_EQ(v.type(), SQL::SQLType::Integer);
|
|
|
|
|
|
|
|
EXPECT(v.to_int().has_value());
|
2021-07-17 07:02:28 -04:00
|
|
|
EXPECT_EQ(v.to_int().value(), 42);
|
|
|
|
}
|
|
|
|
{
|
|
|
|
SQL::Value text("42");
|
|
|
|
SQL::Value integer(SQL::SQLType::Integer);
|
|
|
|
integer = text;
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
|
|
|
|
EXPECT(integer.to_int().has_value());
|
2021-07-17 07:02:28 -04:00
|
|
|
EXPECT_EQ(integer.to_int().value(), 42);
|
|
|
|
}
|
2021-06-17 13:23:52 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
TEST_CASE(serialize_int_value)
|
|
|
|
{
|
2021-07-17 07:02:28 -04:00
|
|
|
SQL::Value v(42);
|
|
|
|
EXPECT_EQ(v.type(), SQL::SQLType::Integer);
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
EXPECT_EQ(v, 42);
|
2021-06-17 13:23:52 -04:00
|
|
|
|
2021-08-18 20:50:13 -04:00
|
|
|
SQL::Serializer serializer;
|
|
|
|
serializer.serialize<SQL::Value>(v);
|
2021-06-17 13:23:52 -04:00
|
|
|
|
2021-08-18 20:50:13 -04:00
|
|
|
serializer.rewind();
|
|
|
|
auto v2 = serializer.deserialize<SQL::Value>();
|
2021-07-17 07:02:28 -04:00
|
|
|
EXPECT_EQ(v2.type(), SQL::SQLType::Integer);
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
EXPECT_EQ(v2, 42);
|
|
|
|
EXPECT_EQ(v2, v);
|
2021-06-17 13:23:52 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
TEST_CASE(float_value)
|
|
|
|
{
|
2021-07-17 07:02:28 -04:00
|
|
|
{
|
|
|
|
SQL::Value v(SQL::SQLType::Float);
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
EXPECT_EQ(v.type(), SQL::SQLType::Float);
|
2021-07-17 07:02:28 -04:00
|
|
|
EXPECT(v.is_null());
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
|
2021-07-17 07:02:28 -04:00
|
|
|
v = 3.14;
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
EXPECT_EQ(v.type(), SQL::SQLType::Float);
|
|
|
|
|
2021-07-17 07:02:28 -04:00
|
|
|
EXPECT(v.to_double().has_value());
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
EXPECT((v.to_double().value() - 3.14) < NumericLimits<double>().epsilon());
|
|
|
|
|
2021-07-17 07:02:28 -04:00
|
|
|
EXPECT(v.to_int().has_value());
|
|
|
|
EXPECT_EQ(v.to_int().value(), 3);
|
2022-12-06 01:12:49 +00:00
|
|
|
EXPECT_EQ(v.to_deprecated_string(), "3.14");
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
|
2022-02-11 09:43:02 -05:00
|
|
|
EXPECT(v.to_bool().has_value());
|
|
|
|
EXPECT(v.to_bool().value());
|
|
|
|
|
|
|
|
v = 0.0;
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
EXPECT_EQ(v.type(), SQL::SQLType::Float);
|
|
|
|
|
2022-02-11 09:43:02 -05:00
|
|
|
EXPECT(v.to_double().has_value());
|
|
|
|
EXPECT(v.to_double().value() < NumericLimits<double>().epsilon());
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
|
2022-02-11 09:43:02 -05:00
|
|
|
EXPECT(v.to_int().has_value());
|
|
|
|
EXPECT_EQ(v.to_int().value(), 0);
|
2022-12-06 01:12:49 +00:00
|
|
|
EXPECT_EQ(v.to_deprecated_string(), "0"sv);
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
|
2022-02-11 09:43:02 -05:00
|
|
|
EXPECT(v.to_bool().has_value());
|
|
|
|
EXPECT(!v.to_bool().value());
|
2021-07-17 07:02:28 -04:00
|
|
|
}
|
|
|
|
{
|
|
|
|
SQL::Value v(3.14);
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
EXPECT_EQ(v.type(), SQL::SQLType::Float);
|
|
|
|
EXPECT((v.to_double().value() - 3.14) < NumericLimits<double>().epsilon());
|
2021-07-17 07:02:28 -04:00
|
|
|
}
|
|
|
|
{
|
|
|
|
SQL::Value v(3.51);
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
EXPECT_EQ(v.type(), SQL::SQLType::Float);
|
|
|
|
|
|
|
|
EXPECT(v.to_int().has_value());
|
2021-07-17 07:02:28 -04:00
|
|
|
EXPECT_EQ(v.to_int().value(), 4);
|
|
|
|
}
|
|
|
|
{
|
|
|
|
SQL::Value v(-3.14);
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
EXPECT_EQ(v.type(), SQL::SQLType::Float);
|
|
|
|
|
|
|
|
EXPECT(v.to_int().has_value());
|
2021-07-17 07:02:28 -04:00
|
|
|
EXPECT_EQ(v.to_int().value(), -3);
|
|
|
|
}
|
|
|
|
{
|
|
|
|
SQL::Value v(-3.51);
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
EXPECT_EQ(v.type(), SQL::SQLType::Float);
|
|
|
|
|
|
|
|
EXPECT(v.to_int().has_value());
|
2021-07-17 07:02:28 -04:00
|
|
|
EXPECT_EQ(v.to_int().value(), -4);
|
|
|
|
}
|
2021-06-17 13:23:52 -04:00
|
|
|
}
|
|
|
|
|
2021-07-17 07:02:28 -04:00
|
|
|
TEST_CASE(serialize_float_value)
|
2021-06-17 13:23:52 -04:00
|
|
|
{
|
2021-07-17 07:02:28 -04:00
|
|
|
SQL::Value v(3.14);
|
|
|
|
EXPECT_EQ(v.type(), SQL::SQLType::Float);
|
|
|
|
EXPECT(v.to_double().value() - 3.14 < NumericLimits<double>().epsilon());
|
|
|
|
|
2021-08-18 20:50:13 -04:00
|
|
|
SQL::Serializer serializer;
|
|
|
|
serializer.serialize<SQL::Value>(v);
|
2021-07-17 07:02:28 -04:00
|
|
|
|
2021-08-18 20:50:13 -04:00
|
|
|
serializer.rewind();
|
|
|
|
auto v2 = serializer.deserialize<SQL::Value>();
|
2021-07-17 07:02:28 -04:00
|
|
|
EXPECT_EQ(v2.type(), SQL::SQLType::Float);
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
EXPECT((v.to_double().value() - 3.14) < NumericLimits<double>().epsilon());
|
|
|
|
EXPECT_EQ(v2, v);
|
2021-06-17 13:23:52 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
TEST_CASE(copy_value)
|
|
|
|
{
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
SQL::Value text("42");
|
2021-06-17 13:23:52 -04:00
|
|
|
SQL::Value copy(text);
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
EXPECT_EQ(copy, "42"sv);
|
2021-06-17 13:23:52 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
TEST_CASE(compare_text_to_int)
|
|
|
|
{
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
SQL::Value text("42");
|
|
|
|
SQL::Value integer(42);
|
|
|
|
EXPECT_EQ(text, integer);
|
|
|
|
EXPECT_EQ(integer, text);
|
2021-06-17 13:23:52 -04:00
|
|
|
}
|
|
|
|
|
2021-07-17 07:02:28 -04:00
|
|
|
TEST_CASE(bool_value)
|
|
|
|
{
|
|
|
|
{
|
|
|
|
SQL::Value v(SQL::SQLType::Boolean);
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
EXPECT_EQ(v.type(), SQL::SQLType::Boolean);
|
2021-07-17 07:02:28 -04:00
|
|
|
EXPECT(v.is_null());
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
|
2021-07-17 07:02:28 -04:00
|
|
|
v = true;
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
EXPECT_EQ(v.type(), SQL::SQLType::Boolean);
|
|
|
|
|
2021-07-17 07:02:28 -04:00
|
|
|
EXPECT(v.to_bool().has_value());
|
|
|
|
EXPECT(v.to_bool().value());
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
|
|
|
|
EXPECT(v.to_int().has_value());
|
2021-07-17 07:02:28 -04:00
|
|
|
EXPECT_EQ(v.to_int().value(), 1);
|
2022-12-06 01:12:49 +00:00
|
|
|
EXPECT_EQ(v.to_deprecated_string(), "true"sv);
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
|
|
|
|
EXPECT(v.to_double().has_value());
|
|
|
|
EXPECT((v.to_double().value() - 1.0) < NumericLimits<double>().epsilon());
|
2021-07-17 07:02:28 -04:00
|
|
|
}
|
|
|
|
{
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
SQL::Value v(false);
|
|
|
|
EXPECT_EQ(v.type(), SQL::SQLType::Boolean);
|
|
|
|
|
2021-07-17 07:02:28 -04:00
|
|
|
EXPECT(v.to_bool().has_value());
|
|
|
|
EXPECT(!v.to_bool().value());
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
|
|
|
|
EXPECT(v.to_int().has_value());
|
2021-07-17 07:02:28 -04:00
|
|
|
EXPECT_EQ(v.to_int().value(), 0);
|
2022-12-06 01:12:49 +00:00
|
|
|
EXPECT_EQ(v.to_deprecated_string(), "false"sv);
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
|
|
|
|
EXPECT(v.to_double().has_value());
|
|
|
|
EXPECT(v.to_double().value() < NumericLimits<double>().epsilon());
|
2021-07-17 07:02:28 -04:00
|
|
|
}
|
|
|
|
{
|
|
|
|
SQL::Value v(true);
|
|
|
|
EXPECT_EQ(v.type(), SQL::SQLType::Boolean);
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
|
2021-07-17 07:02:28 -04:00
|
|
|
EXPECT(v.to_bool().has_value());
|
|
|
|
EXPECT(v.to_bool().value());
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
|
|
|
|
EXPECT(v.to_int().has_value());
|
|
|
|
EXPECT_EQ(v.to_int().value(), 1);
|
2022-12-06 01:12:49 +00:00
|
|
|
EXPECT_EQ(v.to_deprecated_string(), "true"sv);
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
|
|
|
|
EXPECT(v.to_double().has_value());
|
|
|
|
EXPECT((v.to_double().value() - 1.0) < NumericLimits<double>().epsilon());
|
2021-07-17 07:02:28 -04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
TEST_CASE(serialize_boolean_value)
|
|
|
|
{
|
|
|
|
SQL::Value v(true);
|
|
|
|
EXPECT_EQ(v.type(), SQL::SQLType::Boolean);
|
2022-09-22 08:35:47 -04:00
|
|
|
EXPECT_EQ(v.to_bool(), true);
|
2021-07-17 07:02:28 -04:00
|
|
|
|
2021-08-18 20:50:13 -04:00
|
|
|
SQL::Serializer serializer;
|
|
|
|
serializer.serialize<SQL::Value>(v);
|
2021-07-17 07:02:28 -04:00
|
|
|
|
2021-08-18 20:50:13 -04:00
|
|
|
serializer.rewind();
|
|
|
|
auto v2 = serializer.deserialize<SQL::Value>();
|
2021-07-17 07:02:28 -04:00
|
|
|
EXPECT_EQ(v2.type(), SQL::SQLType::Boolean);
|
2022-09-22 08:35:47 -04:00
|
|
|
EXPECT_EQ(v2.to_bool(), true);
|
2021-07-17 07:02:28 -04:00
|
|
|
EXPECT_EQ(v, v2);
|
|
|
|
}
|
|
|
|
|
|
|
|
TEST_CASE(tuple_value)
|
|
|
|
{
|
|
|
|
NonnullRefPtr<SQL::TupleDescriptor> descriptor = adopt_ref(*new SQL::TupleDescriptor);
|
2021-11-02 16:39:00 -04:00
|
|
|
descriptor->append({ "schema", "table", "col1", SQL::SQLType::Text, SQL::Order::Ascending });
|
|
|
|
descriptor->append({ "schema", "table", "col2", SQL::SQLType::Integer, SQL::Order::Descending });
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
auto v = MUST(SQL::Value::create_tuple(move(descriptor)));
|
2021-07-17 07:02:28 -04:00
|
|
|
|
|
|
|
Vector<SQL::Value> values;
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
values.empend("Test");
|
|
|
|
values.empend(42);
|
|
|
|
MUST(v.assign_tuple(values));
|
2021-07-17 07:02:28 -04:00
|
|
|
|
|
|
|
auto values2 = v.to_vector();
|
|
|
|
EXPECT(values2.has_value());
|
|
|
|
EXPECT_EQ(values, values2.value());
|
|
|
|
}
|
|
|
|
|
|
|
|
TEST_CASE(copy_tuple_value)
|
|
|
|
{
|
|
|
|
NonnullRefPtr<SQL::TupleDescriptor> descriptor = adopt_ref(*new SQL::TupleDescriptor);
|
2021-11-02 16:39:00 -04:00
|
|
|
descriptor->append({ "schema", "table", "col1", SQL::SQLType::Text, SQL::Order::Ascending });
|
|
|
|
descriptor->append({ "schema", "table", "col2", SQL::SQLType::Integer, SQL::Order::Descending });
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
auto v = MUST(SQL::Value::create_tuple(move(descriptor)));
|
2021-07-17 07:02:28 -04:00
|
|
|
|
|
|
|
Vector<SQL::Value> values;
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
values.empend("Test");
|
|
|
|
values.empend(42);
|
|
|
|
MUST(v.assign_tuple(values));
|
2021-07-17 07:02:28 -04:00
|
|
|
|
|
|
|
auto values2 = v;
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
EXPECT_EQ(values2.type(), v.type());
|
|
|
|
EXPECT_EQ(v.type(), SQL::SQLType::Tuple);
|
2021-07-17 07:02:28 -04:00
|
|
|
EXPECT_EQ(values, values2.to_vector().value());
|
|
|
|
}
|
|
|
|
|
|
|
|
TEST_CASE(tuple_value_wrong_type)
|
|
|
|
{
|
|
|
|
NonnullRefPtr<SQL::TupleDescriptor> descriptor = adopt_ref(*new SQL::TupleDescriptor);
|
2021-11-02 16:39:00 -04:00
|
|
|
descriptor->append({ "schema", "table", "col1", SQL::SQLType::Text, SQL::Order::Ascending });
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
auto v = MUST(SQL::Value::create_tuple(move(descriptor)));
|
2021-07-17 07:02:28 -04:00
|
|
|
|
|
|
|
Vector<SQL::Value> values;
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
values.empend(42);
|
|
|
|
|
|
|
|
auto result = v.assign_tuple(move(values));
|
|
|
|
EXPECT(result.is_error());
|
2021-07-17 07:02:28 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
TEST_CASE(tuple_value_too_many_values)
|
|
|
|
{
|
|
|
|
NonnullRefPtr<SQL::TupleDescriptor> descriptor = adopt_ref(*new SQL::TupleDescriptor);
|
2021-11-02 16:39:00 -04:00
|
|
|
descriptor->append({ "schema", "table", "col1", SQL::SQLType::Text, SQL::Order::Ascending });
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
auto v = MUST(SQL::Value::create_tuple(move(descriptor)));
|
2021-07-17 07:02:28 -04:00
|
|
|
|
|
|
|
Vector<SQL::Value> values;
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
values.empend("Test");
|
|
|
|
values.empend(42);
|
|
|
|
|
|
|
|
auto result = v.assign_tuple(move(values));
|
|
|
|
EXPECT(result.is_error());
|
2021-07-17 07:02:28 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
TEST_CASE(tuple_value_not_enough_values)
|
|
|
|
{
|
|
|
|
NonnullRefPtr<SQL::TupleDescriptor> descriptor = adopt_ref(*new SQL::TupleDescriptor);
|
2021-11-02 16:39:00 -04:00
|
|
|
descriptor->append({ "schema", "table", "col1", SQL::SQLType::Text, SQL::Order::Ascending });
|
|
|
|
descriptor->append({ "schema", "table", "col2", SQL::SQLType::Integer, SQL::Order::Ascending });
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
auto v = MUST(SQL::Value::create_tuple(move(descriptor)));
|
2021-07-17 07:02:28 -04:00
|
|
|
|
|
|
|
Vector<SQL::Value> values;
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
values.empend("Test");
|
|
|
|
MUST(v.assign_tuple(values));
|
|
|
|
|
|
|
|
EXPECT_EQ(v.type(), SQL::SQLType::Tuple);
|
|
|
|
|
2021-07-17 07:02:28 -04:00
|
|
|
auto values_opt = v.to_vector();
|
|
|
|
EXPECT(values_opt.has_value());
|
|
|
|
EXPECT_EQ(values_opt.value().size(), 2u);
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
|
2021-07-17 07:02:28 -04:00
|
|
|
auto col2 = values_opt.value()[1];
|
|
|
|
EXPECT_EQ(col2.type(), SQL::SQLType::Integer);
|
|
|
|
}
|
|
|
|
|
|
|
|
TEST_CASE(serialize_tuple_value)
|
|
|
|
{
|
|
|
|
NonnullRefPtr<SQL::TupleDescriptor> descriptor = adopt_ref(*new SQL::TupleDescriptor);
|
2021-11-02 16:39:00 -04:00
|
|
|
descriptor->append({ "schema", "table", "col1", SQL::SQLType::Text, SQL::Order::Ascending });
|
|
|
|
descriptor->append({ "schema", "table", "col2", SQL::SQLType::Integer, SQL::Order::Descending });
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
auto v = MUST(SQL::Value::create_tuple(move(descriptor)));
|
2021-07-17 07:02:28 -04:00
|
|
|
|
|
|
|
Vector<SQL::Value> values;
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
values.empend("Test");
|
|
|
|
values.empend(42);
|
|
|
|
MUST(v.assign_tuple(values));
|
2021-07-17 07:02:28 -04:00
|
|
|
|
2021-08-18 20:50:13 -04:00
|
|
|
SQL::Serializer serializer;
|
|
|
|
serializer.serialize<SQL::Value>(v);
|
2021-07-17 07:02:28 -04:00
|
|
|
|
2021-08-18 20:50:13 -04:00
|
|
|
serializer.rewind();
|
|
|
|
auto v2 = serializer.deserialize<SQL::Value>();
|
2021-07-17 07:02:28 -04:00
|
|
|
EXPECT_EQ(v2.type(), SQL::SQLType::Tuple);
|
|
|
|
EXPECT_EQ(v, v2);
|
|
|
|
}
|
|
|
|
|
2021-06-17 13:23:52 -04:00
|
|
|
TEST_CASE(order_text_values)
|
|
|
|
{
|
|
|
|
SQL::Value v1(SQL::SQLType::Text);
|
|
|
|
v1 = "Test_A";
|
|
|
|
SQL::Value v2(SQL::SQLType::Text);
|
|
|
|
v2 = "Test_B";
|
|
|
|
EXPECT(v1 <= v2);
|
|
|
|
EXPECT(v1 < v2);
|
|
|
|
EXPECT(v2 >= v1);
|
|
|
|
EXPECT(v2 > v1);
|
|
|
|
}
|
|
|
|
|
|
|
|
TEST_CASE(order_int_values)
|
|
|
|
{
|
|
|
|
SQL::Value v1(SQL::SQLType::Integer);
|
|
|
|
v1 = 12;
|
|
|
|
SQL::Value v2(SQL::SQLType::Integer);
|
|
|
|
v2 = 42;
|
|
|
|
EXPECT(v1 <= v2);
|
|
|
|
EXPECT(v1 < v2);
|
|
|
|
EXPECT(v2 >= v1);
|
|
|
|
EXPECT(v2 > v1);
|
|
|
|
}
|
|
|
|
|
|
|
|
TEST_CASE(tuple)
|
|
|
|
{
|
2021-07-13 13:47:08 -04:00
|
|
|
NonnullRefPtr<SQL::TupleDescriptor> descriptor = adopt_ref(*new SQL::TupleDescriptor);
|
2021-11-02 16:39:00 -04:00
|
|
|
descriptor->append({ "schema", "table", "col1", SQL::SQLType::Text, SQL::Order::Ascending });
|
|
|
|
descriptor->append({ "schema", "table", "col2", SQL::SQLType::Integer, SQL::Order::Descending });
|
2021-06-17 13:23:52 -04:00
|
|
|
SQL::Tuple tuple(descriptor);
|
|
|
|
|
|
|
|
tuple["col1"] = "Test";
|
|
|
|
tuple["col2"] = 42;
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
EXPECT_EQ(tuple[0], "Test"sv);
|
|
|
|
EXPECT_EQ(tuple[1], 42);
|
2021-06-17 13:23:52 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
TEST_CASE(serialize_tuple)
|
|
|
|
{
|
2021-07-13 13:47:08 -04:00
|
|
|
NonnullRefPtr<SQL::TupleDescriptor> descriptor = adopt_ref(*new SQL::TupleDescriptor);
|
2021-11-02 16:39:00 -04:00
|
|
|
descriptor->append({ "schema", "table", "col1", SQL::SQLType::Text, SQL::Order::Ascending });
|
|
|
|
descriptor->append({ "schema", "table", "col2", SQL::SQLType::Integer, SQL::Order::Descending });
|
2021-06-17 13:23:52 -04:00
|
|
|
SQL::Tuple tuple(descriptor);
|
|
|
|
|
|
|
|
tuple["col1"] = "Test";
|
|
|
|
tuple["col2"] = 42;
|
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
EXPECT_EQ(tuple[0], "Test"sv);
|
2022-09-22 08:35:47 -04:00
|
|
|
EXPECT_EQ(tuple[1], 42);
|
2021-06-17 13:23:52 -04:00
|
|
|
|
2021-08-18 20:50:13 -04:00
|
|
|
SQL::Serializer serializer;
|
|
|
|
serializer.serialize<SQL::Tuple>(tuple);
|
|
|
|
|
|
|
|
serializer.rewind();
|
|
|
|
auto tuple2 = serializer.deserialize<SQL::Tuple>();
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
EXPECT_EQ(tuple2[0], "Test"sv);
|
|
|
|
EXPECT_EQ(tuple2[1], 42);
|
2021-06-17 13:23:52 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
TEST_CASE(copy_tuple)
|
|
|
|
{
|
2021-07-13 13:47:08 -04:00
|
|
|
NonnullRefPtr<SQL::TupleDescriptor> descriptor = adopt_ref(*new SQL::TupleDescriptor);
|
2021-11-02 16:39:00 -04:00
|
|
|
descriptor->append({ "schema", "table", "col1", SQL::SQLType::Text, SQL::Order::Ascending });
|
|
|
|
descriptor->append({ "schema", "table", "col2", SQL::SQLType::Integer, SQL::Order::Descending });
|
2021-06-17 13:23:52 -04:00
|
|
|
SQL::Tuple tuple(descriptor);
|
|
|
|
|
|
|
|
tuple["col1"] = "Test";
|
|
|
|
tuple["col2"] = 42;
|
|
|
|
|
|
|
|
SQL::Tuple copy;
|
|
|
|
copy = tuple;
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
EXPECT_EQ(tuple, copy);
|
2021-06-17 13:23:52 -04:00
|
|
|
|
|
|
|
SQL::Tuple copy_2(copy);
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
EXPECT_EQ(tuple, copy_2);
|
2021-06-17 13:23:52 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
TEST_CASE(compare_tuples)
|
|
|
|
{
|
2021-07-13 13:47:08 -04:00
|
|
|
NonnullRefPtr<SQL::TupleDescriptor> descriptor = adopt_ref(*new SQL::TupleDescriptor);
|
2021-11-02 16:39:00 -04:00
|
|
|
descriptor->append({ "schema", "table", "col1", SQL::SQLType::Text, SQL::Order::Ascending });
|
|
|
|
descriptor->append({ "schema", "table", "col2", SQL::SQLType::Integer, SQL::Order::Descending });
|
2021-06-17 13:23:52 -04:00
|
|
|
|
|
|
|
SQL::Tuple tuple1(descriptor);
|
|
|
|
tuple1["col1"] = "Test";
|
|
|
|
tuple1["col2"] = 42;
|
|
|
|
|
|
|
|
SQL::Tuple tuple2(descriptor);
|
|
|
|
tuple2["col1"] = "Test";
|
|
|
|
tuple2["col2"] = 12;
|
|
|
|
|
|
|
|
SQL::Tuple tuple3(descriptor);
|
|
|
|
tuple3["col1"] = "Text";
|
|
|
|
tuple3["col2"] = 12;
|
|
|
|
|
|
|
|
EXPECT(tuple1 <= tuple2);
|
|
|
|
EXPECT(tuple1 < tuple2);
|
|
|
|
EXPECT(tuple2 >= tuple1);
|
|
|
|
EXPECT(tuple2 > tuple1);
|
|
|
|
|
|
|
|
EXPECT(tuple1 <= tuple3);
|
|
|
|
EXPECT(tuple1 < tuple3);
|
|
|
|
EXPECT(tuple3 >= tuple1);
|
|
|
|
EXPECT(tuple3 > tuple1);
|
|
|
|
}
|