2021-06-17 17:23:52 +00: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 17:48:02 +00:00
|
|
|
* Copyright (c) 2022, Tim Flynn <trflynn89@serenityos.org>
|
2021-06-17 17:23:52 +00: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 11:02:28 +00:00
|
|
|
TEST_CASE(null_value)
|
2021-06-17 17:23:52 +00:00
|
|
|
{
|
2021-07-17 11:02:28 +00: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 17:48:02 +00: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 17:48:02 +00:00
|
|
|
EXPECT(!v.to_bool().has_value());
|
LibSQL: Support 64-bit integer values and handle overflow errors
Currently, integers are stored in LibSQL as 32-bit signed integers, even
if the provided type is unsigned. This resulted in a series of unchecked
unsigned-to-signed conversions, and prevented storing 64-bit values.
Further, mathematical operations were performed without similar checks,
and without checking for overflow.
This changes SQL::Value to behave like SQLite for INTEGER types. In
SQLite, the INTEGER type does not imply a size or signedness of the
underlying type. Instead, SQLite determines on-the-fly what type is
needed as values are created and updated.
To do so, the SQL::Value variant can now hold an i64 or u64 integer. If
a specific type is requested, invalid conversions are now explictly an
error (e.g. converting a stored -1 to a u64 will fail). When binary
mathematical operations are performed, we now try to coerce the RHS
value to a type that works with the LHS value, failing the operation if
that isn't possible. Any overflow or invalid operation (e.g. bitshifting
a 64-bit value by more than 64 bytes) is an error.
2022-12-11 16:44:11 +00:00
|
|
|
EXPECT(!v.to_int<i32>().has_value());
|
|
|
|
EXPECT(!v.to_int<u32>().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 17:48:02 +00:00
|
|
|
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 11:02:28 +00:00
|
|
|
EXPECT(v.is_null());
|
2021-06-17 17:23:52 +00:00
|
|
|
}
|
|
|
|
|
2021-07-17 11:02:28 +00:00
|
|
|
TEST_CASE(text_value)
|
2021-06-17 17:23:52 +00:00
|
|
|
{
|
2021-07-17 11:02:28 +00: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 17:48:02 +00:00
|
|
|
EXPECT_EQ(v.type(), SQL::SQLType::Text);
|
2021-07-17 11:02:28 +00: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 17:48:02 +00: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 11:02:28 +00: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 17:48:02 +00: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 17:48:02 +00: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 17:48:02 +00: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 11:02:28 +00: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 17:48:02 +00: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 11:02:28 +00: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 17:48:02 +00: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 17:48:02 +00:00
|
|
|
}
|
2021-07-17 11:02:28 +00: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 17:48:02 +00:00
|
|
|
SQL::Value v("42");
|
|
|
|
EXPECT_EQ(v.type(), SQL::SQLType::Text);
|
|
|
|
|
LibSQL: Support 64-bit integer values and handle overflow errors
Currently, integers are stored in LibSQL as 32-bit signed integers, even
if the provided type is unsigned. This resulted in a series of unchecked
unsigned-to-signed conversions, and prevented storing 64-bit values.
Further, mathematical operations were performed without similar checks,
and without checking for overflow.
This changes SQL::Value to behave like SQLite for INTEGER types. In
SQLite, the INTEGER type does not imply a size or signedness of the
underlying type. Instead, SQLite determines on-the-fly what type is
needed as values are created and updated.
To do so, the SQL::Value variant can now hold an i64 or u64 integer. If
a specific type is requested, invalid conversions are now explictly an
error (e.g. converting a stored -1 to a u64 will fail). When binary
mathematical operations are performed, we now try to coerce the RHS
value to a type that works with the LHS value, failing the operation if
that isn't possible. Any overflow or invalid operation (e.g. bitshifting
a 64-bit value by more than 64 bytes) is an error.
2022-12-11 16:44:11 +00:00
|
|
|
EXPECT(v.to_int<i32>().has_value());
|
|
|
|
EXPECT_EQ(v.to_int<i32>().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 17:48:02 +00:00
|
|
|
|
2021-07-17 11:02:28 +00: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 17:48:02 +00:00
|
|
|
EXPECT((v.to_double().value() - 42.0) < NumericLimits<double>().epsilon());
|
2021-07-17 11:02:28 +00: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 17:48:02 +00:00
|
|
|
EXPECT_EQ(v.type(), SQL::SQLType::Text);
|
|
|
|
|
2021-07-17 11:02:28 +00: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 17:48:02 +00:00
|
|
|
EXPECT_EQ(v.type(), SQL::SQLType::Text);
|
|
|
|
|
2021-07-17 11:02:28 +00: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 17:48:02 +00:00
|
|
|
{
|
|
|
|
SQL::Value v("foo");
|
|
|
|
EXPECT_EQ(v.type(), SQL::SQLType::Text);
|
|
|
|
|
|
|
|
EXPECT(!v.to_bool().has_value());
|
LibSQL: Support 64-bit integer values and handle overflow errors
Currently, integers are stored in LibSQL as 32-bit signed integers, even
if the provided type is unsigned. This resulted in a series of unchecked
unsigned-to-signed conversions, and prevented storing 64-bit values.
Further, mathematical operations were performed without similar checks,
and without checking for overflow.
This changes SQL::Value to behave like SQLite for INTEGER types. In
SQLite, the INTEGER type does not imply a size or signedness of the
underlying type. Instead, SQLite determines on-the-fly what type is
needed as values are created and updated.
To do so, the SQL::Value variant can now hold an i64 or u64 integer. If
a specific type is requested, invalid conversions are now explictly an
error (e.g. converting a stored -1 to a u64 will fail). When binary
mathematical operations are performed, we now try to coerce the RHS
value to a type that works with the LHS value, failing the operation if
that isn't possible. Any overflow or invalid operation (e.g. bitshifting
a 64-bit value by more than 64 bytes) is an error.
2022-12-11 16:44:11 +00:00
|
|
|
EXPECT(!v.to_int<i32>().has_value());
|
|
|
|
EXPECT(!v.to_int<u32>().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 17:48:02 +00:00
|
|
|
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 17:23:52 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
TEST_CASE(serialize_text_value)
|
|
|
|
{
|
2021-07-17 11:02:28 +00: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 17:48:02 +00:00
|
|
|
EXPECT_EQ(v.type(), SQL::SQLType::Text);
|
|
|
|
EXPECT_EQ(v, "Test"sv);
|
2021-06-17 17:23:52 +00:00
|
|
|
|
2021-08-19 00:50:13 +00:00
|
|
|
SQL::Serializer serializer;
|
|
|
|
serializer.serialize<SQL::Value>(v);
|
2021-06-17 17:23:52 +00:00
|
|
|
|
2021-08-19 00:50:13 +00: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 17:48:02 +00:00
|
|
|
EXPECT_EQ(v2.type(), SQL::SQLType::Text);
|
|
|
|
EXPECT_EQ(v2, "Test"sv);
|
|
|
|
EXPECT_EQ(v2, v);
|
2021-06-17 17:23:52 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
TEST_CASE(integer_value)
|
|
|
|
{
|
2021-07-17 11:02:28 +00: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 17:48:02 +00:00
|
|
|
EXPECT_EQ(v.type(), SQL::SQLType::Integer);
|
2021-07-17 11:02:28 +00: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 17:48:02 +00:00
|
|
|
|
2021-07-17 11:02:28 +00: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 17:48:02 +00:00
|
|
|
EXPECT_EQ(v.type(), SQL::SQLType::Integer);
|
|
|
|
|
LibSQL: Support 64-bit integer values and handle overflow errors
Currently, integers are stored in LibSQL as 32-bit signed integers, even
if the provided type is unsigned. This resulted in a series of unchecked
unsigned-to-signed conversions, and prevented storing 64-bit values.
Further, mathematical operations were performed without similar checks,
and without checking for overflow.
This changes SQL::Value to behave like SQLite for INTEGER types. In
SQLite, the INTEGER type does not imply a size or signedness of the
underlying type. Instead, SQLite determines on-the-fly what type is
needed as values are created and updated.
To do so, the SQL::Value variant can now hold an i64 or u64 integer. If
a specific type is requested, invalid conversions are now explictly an
error (e.g. converting a stored -1 to a u64 will fail). When binary
mathematical operations are performed, we now try to coerce the RHS
value to a type that works with the LHS value, failing the operation if
that isn't possible. Any overflow or invalid operation (e.g. bitshifting
a 64-bit value by more than 64 bytes) is an error.
2022-12-11 16:44:11 +00:00
|
|
|
EXPECT(v.to_int<i32>().has_value());
|
|
|
|
EXPECT_EQ(v.to_int<i32>().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 17:48:02 +00:00
|
|
|
|
2021-07-17 11:02:28 +00: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 17:48:02 +00:00
|
|
|
EXPECT((v.to_double().value() - 42.0) < NumericLimits<double>().epsilon());
|
|
|
|
|
2021-07-17 11:02:28 +00: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 17:48:02 +00:00
|
|
|
EXPECT_EQ(v.type(), SQL::SQLType::Integer);
|
|
|
|
|
LibSQL: Support 64-bit integer values and handle overflow errors
Currently, integers are stored in LibSQL as 32-bit signed integers, even
if the provided type is unsigned. This resulted in a series of unchecked
unsigned-to-signed conversions, and prevented storing 64-bit values.
Further, mathematical operations were performed without similar checks,
and without checking for overflow.
This changes SQL::Value to behave like SQLite for INTEGER types. In
SQLite, the INTEGER type does not imply a size or signedness of the
underlying type. Instead, SQLite determines on-the-fly what type is
needed as values are created and updated.
To do so, the SQL::Value variant can now hold an i64 or u64 integer. If
a specific type is requested, invalid conversions are now explictly an
error (e.g. converting a stored -1 to a u64 will fail). When binary
mathematical operations are performed, we now try to coerce the RHS
value to a type that works with the LHS value, failing the operation if
that isn't possible. Any overflow or invalid operation (e.g. bitshifting
a 64-bit value by more than 64 bytes) is an error.
2022-12-11 16:44:11 +00:00
|
|
|
EXPECT(v.to_int<i32>().has_value());
|
|
|
|
EXPECT_EQ(v.to_int<i32>().value(), 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 17:48:02 +00:00
|
|
|
|
2021-07-17 11:02:28 +00: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 17:48:02 +00:00
|
|
|
SQL::Value v(42);
|
|
|
|
EXPECT_EQ(v.type(), SQL::SQLType::Integer);
|
|
|
|
|
LibSQL: Support 64-bit integer values and handle overflow errors
Currently, integers are stored in LibSQL as 32-bit signed integers, even
if the provided type is unsigned. This resulted in a series of unchecked
unsigned-to-signed conversions, and prevented storing 64-bit values.
Further, mathematical operations were performed without similar checks,
and without checking for overflow.
This changes SQL::Value to behave like SQLite for INTEGER types. In
SQLite, the INTEGER type does not imply a size or signedness of the
underlying type. Instead, SQLite determines on-the-fly what type is
needed as values are created and updated.
To do so, the SQL::Value variant can now hold an i64 or u64 integer. If
a specific type is requested, invalid conversions are now explictly an
error (e.g. converting a stored -1 to a u64 will fail). When binary
mathematical operations are performed, we now try to coerce the RHS
value to a type that works with the LHS value, failing the operation if
that isn't possible. Any overflow or invalid operation (e.g. bitshifting
a 64-bit value by more than 64 bytes) is an error.
2022-12-11 16:44:11 +00:00
|
|
|
EXPECT(v.to_int<i32>().has_value());
|
|
|
|
EXPECT_EQ(v.to_int<i32>().value(), 42);
|
2021-07-17 11:02:28 +00:00
|
|
|
}
|
|
|
|
{
|
|
|
|
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 17:48:02 +00:00
|
|
|
|
LibSQL: Support 64-bit integer values and handle overflow errors
Currently, integers are stored in LibSQL as 32-bit signed integers, even
if the provided type is unsigned. This resulted in a series of unchecked
unsigned-to-signed conversions, and prevented storing 64-bit values.
Further, mathematical operations were performed without similar checks,
and without checking for overflow.
This changes SQL::Value to behave like SQLite for INTEGER types. In
SQLite, the INTEGER type does not imply a size or signedness of the
underlying type. Instead, SQLite determines on-the-fly what type is
needed as values are created and updated.
To do so, the SQL::Value variant can now hold an i64 or u64 integer. If
a specific type is requested, invalid conversions are now explictly an
error (e.g. converting a stored -1 to a u64 will fail). When binary
mathematical operations are performed, we now try to coerce the RHS
value to a type that works with the LHS value, failing the operation if
that isn't possible. Any overflow or invalid operation (e.g. bitshifting
a 64-bit value by more than 64 bytes) is an error.
2022-12-11 16:44:11 +00:00
|
|
|
EXPECT(integer.to_int<i32>().has_value());
|
|
|
|
EXPECT_EQ(integer.to_int<i32>().value(), 42);
|
2021-07-17 11:02:28 +00:00
|
|
|
}
|
2021-06-17 17:23:52 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
TEST_CASE(serialize_int_value)
|
|
|
|
{
|
2021-07-17 11:02:28 +00: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 17:48:02 +00:00
|
|
|
EXPECT_EQ(v, 42);
|
2021-06-17 17:23:52 +00:00
|
|
|
|
2021-08-19 00:50:13 +00:00
|
|
|
SQL::Serializer serializer;
|
|
|
|
serializer.serialize<SQL::Value>(v);
|
2021-06-17 17:23:52 +00:00
|
|
|
|
2021-08-19 00:50:13 +00:00
|
|
|
serializer.rewind();
|
|
|
|
auto v2 = serializer.deserialize<SQL::Value>();
|
2021-07-17 11:02:28 +00: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 17:48:02 +00:00
|
|
|
EXPECT_EQ(v2, 42);
|
|
|
|
EXPECT_EQ(v2, v);
|
2021-06-17 17:23:52 +00:00
|
|
|
}
|
|
|
|
|
LibSQL: Support 64-bit integer values and handle overflow errors
Currently, integers are stored in LibSQL as 32-bit signed integers, even
if the provided type is unsigned. This resulted in a series of unchecked
unsigned-to-signed conversions, and prevented storing 64-bit values.
Further, mathematical operations were performed without similar checks,
and without checking for overflow.
This changes SQL::Value to behave like SQLite for INTEGER types. In
SQLite, the INTEGER type does not imply a size or signedness of the
underlying type. Instead, SQLite determines on-the-fly what type is
needed as values are created and updated.
To do so, the SQL::Value variant can now hold an i64 or u64 integer. If
a specific type is requested, invalid conversions are now explictly an
error (e.g. converting a stored -1 to a u64 will fail). When binary
mathematical operations are performed, we now try to coerce the RHS
value to a type that works with the LHS value, failing the operation if
that isn't possible. Any overflow or invalid operation (e.g. bitshifting
a 64-bit value by more than 64 bytes) is an error.
2022-12-11 16:44:11 +00:00
|
|
|
TEST_CASE(serialize_downsized_int_value)
|
|
|
|
{
|
|
|
|
auto run_test_for_value = [](auto value) {
|
|
|
|
using T = decltype(value);
|
|
|
|
SQL::Value v(value);
|
|
|
|
|
|
|
|
SQL::Serializer serializer;
|
|
|
|
serializer.serialize(v);
|
|
|
|
serializer.rewind();
|
|
|
|
|
|
|
|
auto type_flags = serializer.deserialize<u8>();
|
|
|
|
auto type_data = type_flags & 0xf0;
|
|
|
|
auto type = static_cast<SQL::SQLType>(type_flags & 0x0f);
|
|
|
|
|
|
|
|
EXPECT_NE(type_data, 0);
|
|
|
|
EXPECT_EQ(type, SQL::SQLType::Integer);
|
|
|
|
|
|
|
|
auto deserialized = serializer.deserialize<T>();
|
|
|
|
EXPECT_EQ(deserialized, value);
|
|
|
|
};
|
|
|
|
|
|
|
|
run_test_for_value(NumericLimits<i8>::min());
|
|
|
|
run_test_for_value(NumericLimits<i8>::max());
|
|
|
|
|
|
|
|
run_test_for_value(NumericLimits<i16>::min());
|
|
|
|
run_test_for_value(NumericLimits<i16>::max());
|
|
|
|
|
|
|
|
run_test_for_value(NumericLimits<i32>::min());
|
|
|
|
run_test_for_value(NumericLimits<i32>::max());
|
|
|
|
|
|
|
|
run_test_for_value(NumericLimits<i64>::min());
|
|
|
|
run_test_for_value(NumericLimits<i64>::max());
|
|
|
|
|
|
|
|
run_test_for_value(NumericLimits<u8>::min());
|
|
|
|
run_test_for_value(NumericLimits<u8>::max());
|
|
|
|
|
|
|
|
run_test_for_value(NumericLimits<u16>::min());
|
|
|
|
run_test_for_value(NumericLimits<u16>::max());
|
|
|
|
|
|
|
|
run_test_for_value(NumericLimits<u32>::min());
|
|
|
|
run_test_for_value(NumericLimits<u32>::max());
|
|
|
|
|
|
|
|
run_test_for_value(NumericLimits<u64>::min());
|
|
|
|
run_test_for_value(NumericLimits<u64>::max());
|
|
|
|
}
|
|
|
|
|
2021-06-17 17:23:52 +00:00
|
|
|
TEST_CASE(float_value)
|
|
|
|
{
|
2021-07-17 11:02:28 +00: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 17:48:02 +00:00
|
|
|
EXPECT_EQ(v.type(), SQL::SQLType::Float);
|
2021-07-17 11:02:28 +00: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 17:48:02 +00:00
|
|
|
|
2021-07-17 11:02:28 +00: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 17:48:02 +00:00
|
|
|
EXPECT_EQ(v.type(), SQL::SQLType::Float);
|
|
|
|
|
2021-07-17 11:02:28 +00: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 17:48:02 +00:00
|
|
|
EXPECT((v.to_double().value() - 3.14) < NumericLimits<double>().epsilon());
|
|
|
|
|
LibSQL: Support 64-bit integer values and handle overflow errors
Currently, integers are stored in LibSQL as 32-bit signed integers, even
if the provided type is unsigned. This resulted in a series of unchecked
unsigned-to-signed conversions, and prevented storing 64-bit values.
Further, mathematical operations were performed without similar checks,
and without checking for overflow.
This changes SQL::Value to behave like SQLite for INTEGER types. In
SQLite, the INTEGER type does not imply a size or signedness of the
underlying type. Instead, SQLite determines on-the-fly what type is
needed as values are created and updated.
To do so, the SQL::Value variant can now hold an i64 or u64 integer. If
a specific type is requested, invalid conversions are now explictly an
error (e.g. converting a stored -1 to a u64 will fail). When binary
mathematical operations are performed, we now try to coerce the RHS
value to a type that works with the LHS value, failing the operation if
that isn't possible. Any overflow or invalid operation (e.g. bitshifting
a 64-bit value by more than 64 bytes) is an error.
2022-12-11 16:44:11 +00:00
|
|
|
EXPECT(v.to_int<i32>().has_value());
|
|
|
|
EXPECT_EQ(v.to_int<i32>().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 17:48:02 +00:00
|
|
|
|
2022-02-11 14:43:02 +00: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 17:48:02 +00:00
|
|
|
EXPECT_EQ(v.type(), SQL::SQLType::Float);
|
|
|
|
|
2022-02-11 14:43:02 +00: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 17:48:02 +00:00
|
|
|
|
LibSQL: Support 64-bit integer values and handle overflow errors
Currently, integers are stored in LibSQL as 32-bit signed integers, even
if the provided type is unsigned. This resulted in a series of unchecked
unsigned-to-signed conversions, and prevented storing 64-bit values.
Further, mathematical operations were performed without similar checks,
and without checking for overflow.
This changes SQL::Value to behave like SQLite for INTEGER types. In
SQLite, the INTEGER type does not imply a size or signedness of the
underlying type. Instead, SQLite determines on-the-fly what type is
needed as values are created and updated.
To do so, the SQL::Value variant can now hold an i64 or u64 integer. If
a specific type is requested, invalid conversions are now explictly an
error (e.g. converting a stored -1 to a u64 will fail). When binary
mathematical operations are performed, we now try to coerce the RHS
value to a type that works with the LHS value, failing the operation if
that isn't possible. Any overflow or invalid operation (e.g. bitshifting
a 64-bit value by more than 64 bytes) is an error.
2022-12-11 16:44:11 +00:00
|
|
|
EXPECT(v.to_int<i32>().has_value());
|
|
|
|
EXPECT_EQ(v.to_int<i32>().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 17:48:02 +00:00
|
|
|
|
2022-02-11 14:43:02 +00:00
|
|
|
EXPECT(v.to_bool().has_value());
|
|
|
|
EXPECT(!v.to_bool().value());
|
2021-07-17 11:02:28 +00: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 17:48:02 +00:00
|
|
|
EXPECT_EQ(v.type(), SQL::SQLType::Float);
|
|
|
|
EXPECT((v.to_double().value() - 3.14) < NumericLimits<double>().epsilon());
|
2021-07-17 11:02:28 +00: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 17:48:02 +00:00
|
|
|
EXPECT_EQ(v.type(), SQL::SQLType::Float);
|
|
|
|
|
LibSQL: Support 64-bit integer values and handle overflow errors
Currently, integers are stored in LibSQL as 32-bit signed integers, even
if the provided type is unsigned. This resulted in a series of unchecked
unsigned-to-signed conversions, and prevented storing 64-bit values.
Further, mathematical operations were performed without similar checks,
and without checking for overflow.
This changes SQL::Value to behave like SQLite for INTEGER types. In
SQLite, the INTEGER type does not imply a size or signedness of the
underlying type. Instead, SQLite determines on-the-fly what type is
needed as values are created and updated.
To do so, the SQL::Value variant can now hold an i64 or u64 integer. If
a specific type is requested, invalid conversions are now explictly an
error (e.g. converting a stored -1 to a u64 will fail). When binary
mathematical operations are performed, we now try to coerce the RHS
value to a type that works with the LHS value, failing the operation if
that isn't possible. Any overflow or invalid operation (e.g. bitshifting
a 64-bit value by more than 64 bytes) is an error.
2022-12-11 16:44:11 +00:00
|
|
|
EXPECT(v.to_int<i32>().has_value());
|
|
|
|
EXPECT_EQ(v.to_int<i32>().value(), 4);
|
2021-07-17 11:02:28 +00: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 17:48:02 +00:00
|
|
|
EXPECT_EQ(v.type(), SQL::SQLType::Float);
|
|
|
|
|
LibSQL: Support 64-bit integer values and handle overflow errors
Currently, integers are stored in LibSQL as 32-bit signed integers, even
if the provided type is unsigned. This resulted in a series of unchecked
unsigned-to-signed conversions, and prevented storing 64-bit values.
Further, mathematical operations were performed without similar checks,
and without checking for overflow.
This changes SQL::Value to behave like SQLite for INTEGER types. In
SQLite, the INTEGER type does not imply a size or signedness of the
underlying type. Instead, SQLite determines on-the-fly what type is
needed as values are created and updated.
To do so, the SQL::Value variant can now hold an i64 or u64 integer. If
a specific type is requested, invalid conversions are now explictly an
error (e.g. converting a stored -1 to a u64 will fail). When binary
mathematical operations are performed, we now try to coerce the RHS
value to a type that works with the LHS value, failing the operation if
that isn't possible. Any overflow or invalid operation (e.g. bitshifting
a 64-bit value by more than 64 bytes) is an error.
2022-12-11 16:44:11 +00:00
|
|
|
EXPECT(v.to_int<i32>().has_value());
|
|
|
|
EXPECT_EQ(v.to_int<i32>().value(), -3);
|
2021-07-17 11:02:28 +00: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 17:48:02 +00:00
|
|
|
EXPECT_EQ(v.type(), SQL::SQLType::Float);
|
|
|
|
|
LibSQL: Support 64-bit integer values and handle overflow errors
Currently, integers are stored in LibSQL as 32-bit signed integers, even
if the provided type is unsigned. This resulted in a series of unchecked
unsigned-to-signed conversions, and prevented storing 64-bit values.
Further, mathematical operations were performed without similar checks,
and without checking for overflow.
This changes SQL::Value to behave like SQLite for INTEGER types. In
SQLite, the INTEGER type does not imply a size or signedness of the
underlying type. Instead, SQLite determines on-the-fly what type is
needed as values are created and updated.
To do so, the SQL::Value variant can now hold an i64 or u64 integer. If
a specific type is requested, invalid conversions are now explictly an
error (e.g. converting a stored -1 to a u64 will fail). When binary
mathematical operations are performed, we now try to coerce the RHS
value to a type that works with the LHS value, failing the operation if
that isn't possible. Any overflow or invalid operation (e.g. bitshifting
a 64-bit value by more than 64 bytes) is an error.
2022-12-11 16:44:11 +00:00
|
|
|
EXPECT(v.to_int<i32>().has_value());
|
|
|
|
EXPECT_EQ(v.to_int<i32>().value(), -4);
|
2021-07-17 11:02:28 +00:00
|
|
|
}
|
2021-06-17 17:23:52 +00:00
|
|
|
}
|
|
|
|
|
2021-07-17 11:02:28 +00:00
|
|
|
TEST_CASE(serialize_float_value)
|
2021-06-17 17:23:52 +00:00
|
|
|
{
|
2021-07-17 11:02:28 +00: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-19 00:50:13 +00:00
|
|
|
SQL::Serializer serializer;
|
|
|
|
serializer.serialize<SQL::Value>(v);
|
2021-07-17 11:02:28 +00:00
|
|
|
|
2021-08-19 00:50:13 +00:00
|
|
|
serializer.rewind();
|
|
|
|
auto v2 = serializer.deserialize<SQL::Value>();
|
2021-07-17 11:02:28 +00: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 17:48:02 +00:00
|
|
|
EXPECT((v.to_double().value() - 3.14) < NumericLimits<double>().epsilon());
|
|
|
|
EXPECT_EQ(v2, v);
|
2021-06-17 17:23:52 +00: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 17:48:02 +00:00
|
|
|
SQL::Value text("42");
|
2021-06-17 17:23:52 +00: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 17:48:02 +00:00
|
|
|
EXPECT_EQ(copy, "42"sv);
|
2021-06-17 17:23:52 +00:00
|
|
|
}
|
|
|
|
|
LibSQL: Support 64-bit integer values and handle overflow errors
Currently, integers are stored in LibSQL as 32-bit signed integers, even
if the provided type is unsigned. This resulted in a series of unchecked
unsigned-to-signed conversions, and prevented storing 64-bit values.
Further, mathematical operations were performed without similar checks,
and without checking for overflow.
This changes SQL::Value to behave like SQLite for INTEGER types. In
SQLite, the INTEGER type does not imply a size or signedness of the
underlying type. Instead, SQLite determines on-the-fly what type is
needed as values are created and updated.
To do so, the SQL::Value variant can now hold an i64 or u64 integer. If
a specific type is requested, invalid conversions are now explictly an
error (e.g. converting a stored -1 to a u64 will fail). When binary
mathematical operations are performed, we now try to coerce the RHS
value to a type that works with the LHS value, failing the operation if
that isn't possible. Any overflow or invalid operation (e.g. bitshifting
a 64-bit value by more than 64 bytes) is an error.
2022-12-11 16:44:11 +00:00
|
|
|
TEST_CASE(to_int)
|
2021-06-17 17:23:52 +00: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 17:48:02 +00:00
|
|
|
SQL::Value text("42");
|
|
|
|
SQL::Value integer(42);
|
|
|
|
EXPECT_EQ(text, integer);
|
|
|
|
EXPECT_EQ(integer, text);
|
LibSQL: Support 64-bit integer values and handle overflow errors
Currently, integers are stored in LibSQL as 32-bit signed integers, even
if the provided type is unsigned. This resulted in a series of unchecked
unsigned-to-signed conversions, and prevented storing 64-bit values.
Further, mathematical operations were performed without similar checks,
and without checking for overflow.
This changes SQL::Value to behave like SQLite for INTEGER types. In
SQLite, the INTEGER type does not imply a size or signedness of the
underlying type. Instead, SQLite determines on-the-fly what type is
needed as values are created and updated.
To do so, the SQL::Value variant can now hold an i64 or u64 integer. If
a specific type is requested, invalid conversions are now explictly an
error (e.g. converting a stored -1 to a u64 will fail). When binary
mathematical operations are performed, we now try to coerce the RHS
value to a type that works with the LHS value, failing the operation if
that isn't possible. Any overflow or invalid operation (e.g. bitshifting
a 64-bit value by more than 64 bytes) is an error.
2022-12-11 16:44:11 +00:00
|
|
|
|
|
|
|
SQL::Value int_64 { static_cast<i64>(123) };
|
|
|
|
EXPECT_EQ(int_64.to_int<i8>(), 123);
|
|
|
|
EXPECT_EQ(int_64.to_int<i16>(), 123);
|
|
|
|
EXPECT_EQ(int_64.to_int<i32>(), 123);
|
|
|
|
EXPECT_EQ(int_64.to_int<u8>(), 123u);
|
|
|
|
EXPECT_EQ(int_64.to_int<u16>(), 123u);
|
|
|
|
EXPECT_EQ(int_64.to_int<u32>(), 123u);
|
|
|
|
EXPECT_EQ(int_64.to_int<u64>(), 123u);
|
|
|
|
|
|
|
|
SQL::Value uint_64 { static_cast<i64>(123) };
|
|
|
|
EXPECT_EQ(uint_64.to_int<i8>(), 123);
|
|
|
|
EXPECT_EQ(uint_64.to_int<i16>(), 123);
|
|
|
|
EXPECT_EQ(uint_64.to_int<i32>(), 123);
|
|
|
|
EXPECT_EQ(uint_64.to_int<i64>(), 123);
|
|
|
|
EXPECT_EQ(uint_64.to_int<u8>(), 123u);
|
|
|
|
EXPECT_EQ(uint_64.to_int<u16>(), 123u);
|
|
|
|
EXPECT_EQ(uint_64.to_int<u32>(), 123u);
|
|
|
|
}
|
|
|
|
|
|
|
|
TEST_CASE(to_int_failures)
|
|
|
|
{
|
|
|
|
SQL::Value large_int_64 { NumericLimits<i64>::max() };
|
|
|
|
EXPECT(!large_int_64.to_int<i8>().has_value());
|
|
|
|
EXPECT(!large_int_64.to_int<i16>().has_value());
|
|
|
|
EXPECT(!large_int_64.to_int<i32>().has_value());
|
|
|
|
EXPECT(!large_int_64.to_int<u8>().has_value());
|
|
|
|
EXPECT(!large_int_64.to_int<u16>().has_value());
|
|
|
|
EXPECT(!large_int_64.to_int<u32>().has_value());
|
|
|
|
|
|
|
|
SQL::Value large_int_32 { NumericLimits<i32>::max() };
|
|
|
|
EXPECT(!large_int_32.to_int<i8>().has_value());
|
|
|
|
EXPECT(!large_int_32.to_int<i16>().has_value());
|
|
|
|
EXPECT(!large_int_32.to_int<u8>().has_value());
|
|
|
|
EXPECT(!large_int_32.to_int<u16>().has_value());
|
|
|
|
|
|
|
|
SQL::Value small_int_64 { NumericLimits<i64>::min() };
|
|
|
|
EXPECT(!small_int_64.to_int<i8>().has_value());
|
|
|
|
EXPECT(!small_int_64.to_int<i16>().has_value());
|
|
|
|
EXPECT(!small_int_64.to_int<i32>().has_value());
|
|
|
|
EXPECT(!small_int_64.to_int<u8>().has_value());
|
|
|
|
EXPECT(!small_int_64.to_int<u16>().has_value());
|
|
|
|
EXPECT(!small_int_64.to_int<u32>().has_value());
|
|
|
|
EXPECT(!small_int_64.to_int<u64>().has_value());
|
|
|
|
|
|
|
|
SQL::Value small_int_32 { NumericLimits<i32>::min() };
|
|
|
|
EXPECT(!small_int_32.to_int<i8>().has_value());
|
|
|
|
EXPECT(!small_int_32.to_int<i16>().has_value());
|
|
|
|
EXPECT(!small_int_32.to_int<u8>().has_value());
|
|
|
|
EXPECT(!small_int_32.to_int<u16>().has_value());
|
|
|
|
EXPECT(!small_int_32.to_int<u32>().has_value());
|
|
|
|
EXPECT(!small_int_32.to_int<u64>().has_value());
|
|
|
|
|
|
|
|
SQL::Value large_uint_64 { NumericLimits<u64>::max() };
|
|
|
|
EXPECT(!large_uint_64.to_int<i8>().has_value());
|
|
|
|
EXPECT(!large_uint_64.to_int<i16>().has_value());
|
|
|
|
EXPECT(!large_uint_64.to_int<i32>().has_value());
|
|
|
|
EXPECT(!large_uint_64.to_int<i64>().has_value());
|
|
|
|
EXPECT(!large_uint_64.to_int<u8>().has_value());
|
|
|
|
EXPECT(!large_uint_64.to_int<u16>().has_value());
|
|
|
|
EXPECT(!large_uint_64.to_int<u32>().has_value());
|
|
|
|
|
|
|
|
SQL::Value large_uint_32 { NumericLimits<u32>::max() };
|
|
|
|
EXPECT(!large_uint_32.to_int<i8>().has_value());
|
|
|
|
EXPECT(!large_uint_32.to_int<i16>().has_value());
|
|
|
|
EXPECT(!large_uint_32.to_int<u8>().has_value());
|
|
|
|
EXPECT(!large_uint_32.to_int<u16>().has_value());
|
2021-06-17 17:23:52 +00:00
|
|
|
}
|
|
|
|
|
2021-07-17 11:02:28 +00: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 17:48:02 +00:00
|
|
|
EXPECT_EQ(v.type(), SQL::SQLType::Boolean);
|
2021-07-17 11:02:28 +00: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 17:48:02 +00:00
|
|
|
|
2021-07-17 11:02:28 +00: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 17:48:02 +00:00
|
|
|
EXPECT_EQ(v.type(), SQL::SQLType::Boolean);
|
|
|
|
|
2021-07-17 11:02:28 +00: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 17:48:02 +00:00
|
|
|
|
LibSQL: Support 64-bit integer values and handle overflow errors
Currently, integers are stored in LibSQL as 32-bit signed integers, even
if the provided type is unsigned. This resulted in a series of unchecked
unsigned-to-signed conversions, and prevented storing 64-bit values.
Further, mathematical operations were performed without similar checks,
and without checking for overflow.
This changes SQL::Value to behave like SQLite for INTEGER types. In
SQLite, the INTEGER type does not imply a size or signedness of the
underlying type. Instead, SQLite determines on-the-fly what type is
needed as values are created and updated.
To do so, the SQL::Value variant can now hold an i64 or u64 integer. If
a specific type is requested, invalid conversions are now explictly an
error (e.g. converting a stored -1 to a u64 will fail). When binary
mathematical operations are performed, we now try to coerce the RHS
value to a type that works with the LHS value, failing the operation if
that isn't possible. Any overflow or invalid operation (e.g. bitshifting
a 64-bit value by more than 64 bytes) is an error.
2022-12-11 16:44:11 +00:00
|
|
|
EXPECT(v.to_int<i32>().has_value());
|
|
|
|
EXPECT_EQ(v.to_int<i32>().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 17:48:02 +00:00
|
|
|
|
|
|
|
EXPECT(v.to_double().has_value());
|
|
|
|
EXPECT((v.to_double().value() - 1.0) < NumericLimits<double>().epsilon());
|
2021-07-17 11:02:28 +00: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 17:48:02 +00:00
|
|
|
SQL::Value v(false);
|
|
|
|
EXPECT_EQ(v.type(), SQL::SQLType::Boolean);
|
|
|
|
|
2021-07-17 11:02:28 +00: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 17:48:02 +00:00
|
|
|
|
LibSQL: Support 64-bit integer values and handle overflow errors
Currently, integers are stored in LibSQL as 32-bit signed integers, even
if the provided type is unsigned. This resulted in a series of unchecked
unsigned-to-signed conversions, and prevented storing 64-bit values.
Further, mathematical operations were performed without similar checks,
and without checking for overflow.
This changes SQL::Value to behave like SQLite for INTEGER types. In
SQLite, the INTEGER type does not imply a size or signedness of the
underlying type. Instead, SQLite determines on-the-fly what type is
needed as values are created and updated.
To do so, the SQL::Value variant can now hold an i64 or u64 integer. If
a specific type is requested, invalid conversions are now explictly an
error (e.g. converting a stored -1 to a u64 will fail). When binary
mathematical operations are performed, we now try to coerce the RHS
value to a type that works with the LHS value, failing the operation if
that isn't possible. Any overflow or invalid operation (e.g. bitshifting
a 64-bit value by more than 64 bytes) is an error.
2022-12-11 16:44:11 +00:00
|
|
|
EXPECT(v.to_int<i32>().has_value());
|
|
|
|
EXPECT_EQ(v.to_int<i32>().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 17:48:02 +00:00
|
|
|
|
|
|
|
EXPECT(v.to_double().has_value());
|
|
|
|
EXPECT(v.to_double().value() < NumericLimits<double>().epsilon());
|
2021-07-17 11:02:28 +00: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 17:48:02 +00:00
|
|
|
|
2021-07-17 11:02:28 +00: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 17:48:02 +00:00
|
|
|
|
LibSQL: Support 64-bit integer values and handle overflow errors
Currently, integers are stored in LibSQL as 32-bit signed integers, even
if the provided type is unsigned. This resulted in a series of unchecked
unsigned-to-signed conversions, and prevented storing 64-bit values.
Further, mathematical operations were performed without similar checks,
and without checking for overflow.
This changes SQL::Value to behave like SQLite for INTEGER types. In
SQLite, the INTEGER type does not imply a size or signedness of the
underlying type. Instead, SQLite determines on-the-fly what type is
needed as values are created and updated.
To do so, the SQL::Value variant can now hold an i64 or u64 integer. If
a specific type is requested, invalid conversions are now explictly an
error (e.g. converting a stored -1 to a u64 will fail). When binary
mathematical operations are performed, we now try to coerce the RHS
value to a type that works with the LHS value, failing the operation if
that isn't possible. Any overflow or invalid operation (e.g. bitshifting
a 64-bit value by more than 64 bytes) is an error.
2022-12-11 16:44:11 +00:00
|
|
|
EXPECT(v.to_int<i32>().has_value());
|
|
|
|
EXPECT_EQ(v.to_int<i32>().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 17:48:02 +00:00
|
|
|
|
|
|
|
EXPECT(v.to_double().has_value());
|
|
|
|
EXPECT((v.to_double().value() - 1.0) < NumericLimits<double>().epsilon());
|
2021-07-17 11:02:28 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
TEST_CASE(serialize_boolean_value)
|
|
|
|
{
|
|
|
|
SQL::Value v(true);
|
|
|
|
EXPECT_EQ(v.type(), SQL::SQLType::Boolean);
|
2022-09-22 12:35:47 +00:00
|
|
|
EXPECT_EQ(v.to_bool(), true);
|
2021-07-17 11:02:28 +00:00
|
|
|
|
2021-08-19 00:50:13 +00:00
|
|
|
SQL::Serializer serializer;
|
|
|
|
serializer.serialize<SQL::Value>(v);
|
2021-07-17 11:02:28 +00:00
|
|
|
|
2021-08-19 00:50:13 +00:00
|
|
|
serializer.rewind();
|
|
|
|
auto v2 = serializer.deserialize<SQL::Value>();
|
2021-07-17 11:02:28 +00:00
|
|
|
EXPECT_EQ(v2.type(), SQL::SQLType::Boolean);
|
2022-09-22 12:35:47 +00:00
|
|
|
EXPECT_EQ(v2.to_bool(), true);
|
2021-07-17 11:02:28 +00:00
|
|
|
EXPECT_EQ(v, v2);
|
|
|
|
}
|
|
|
|
|
|
|
|
TEST_CASE(tuple_value)
|
|
|
|
{
|
|
|
|
NonnullRefPtr<SQL::TupleDescriptor> descriptor = adopt_ref(*new SQL::TupleDescriptor);
|
2021-11-02 20:39:00 +00: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 17:48:02 +00:00
|
|
|
auto v = MUST(SQL::Value::create_tuple(move(descriptor)));
|
2021-07-17 11:02:28 +00: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 17:48:02 +00:00
|
|
|
values.empend("Test");
|
|
|
|
values.empend(42);
|
|
|
|
MUST(v.assign_tuple(values));
|
2021-07-17 11:02:28 +00: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 20:39:00 +00: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 17:48:02 +00:00
|
|
|
auto v = MUST(SQL::Value::create_tuple(move(descriptor)));
|
2021-07-17 11:02:28 +00: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 17:48:02 +00:00
|
|
|
values.empend("Test");
|
|
|
|
values.empend(42);
|
|
|
|
MUST(v.assign_tuple(values));
|
2021-07-17 11:02:28 +00: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 17:48:02 +00:00
|
|
|
EXPECT_EQ(values2.type(), v.type());
|
|
|
|
EXPECT_EQ(v.type(), SQL::SQLType::Tuple);
|
2021-07-17 11:02:28 +00: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 20:39:00 +00: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 17:48:02 +00:00
|
|
|
auto v = MUST(SQL::Value::create_tuple(move(descriptor)));
|
2021-07-17 11:02:28 +00: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 17:48:02 +00:00
|
|
|
values.empend(42);
|
|
|
|
|
|
|
|
auto result = v.assign_tuple(move(values));
|
|
|
|
EXPECT(result.is_error());
|
2021-07-17 11:02:28 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
TEST_CASE(tuple_value_too_many_values)
|
|
|
|
{
|
|
|
|
NonnullRefPtr<SQL::TupleDescriptor> descriptor = adopt_ref(*new SQL::TupleDescriptor);
|
2021-11-02 20:39:00 +00: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 17:48:02 +00:00
|
|
|
auto v = MUST(SQL::Value::create_tuple(move(descriptor)));
|
2021-07-17 11:02:28 +00: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 17:48:02 +00:00
|
|
|
values.empend("Test");
|
|
|
|
values.empend(42);
|
|
|
|
|
|
|
|
auto result = v.assign_tuple(move(values));
|
|
|
|
EXPECT(result.is_error());
|
2021-07-17 11:02:28 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
TEST_CASE(tuple_value_not_enough_values)
|
|
|
|
{
|
|
|
|
NonnullRefPtr<SQL::TupleDescriptor> descriptor = adopt_ref(*new SQL::TupleDescriptor);
|
2021-11-02 20:39:00 +00: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 17:48:02 +00:00
|
|
|
auto v = MUST(SQL::Value::create_tuple(move(descriptor)));
|
2021-07-17 11:02:28 +00: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 17:48:02 +00:00
|
|
|
values.empend("Test");
|
|
|
|
MUST(v.assign_tuple(values));
|
|
|
|
|
|
|
|
EXPECT_EQ(v.type(), SQL::SQLType::Tuple);
|
|
|
|
|
2021-07-17 11:02:28 +00: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 17:48:02 +00:00
|
|
|
|
2021-07-17 11:02:28 +00: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 20:39:00 +00: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 17:48:02 +00:00
|
|
|
auto v = MUST(SQL::Value::create_tuple(move(descriptor)));
|
2021-07-17 11:02:28 +00: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 17:48:02 +00:00
|
|
|
values.empend("Test");
|
|
|
|
values.empend(42);
|
|
|
|
MUST(v.assign_tuple(values));
|
2021-07-17 11:02:28 +00:00
|
|
|
|
2021-08-19 00:50:13 +00:00
|
|
|
SQL::Serializer serializer;
|
|
|
|
serializer.serialize<SQL::Value>(v);
|
2021-07-17 11:02:28 +00:00
|
|
|
|
2021-08-19 00:50:13 +00:00
|
|
|
serializer.rewind();
|
|
|
|
auto v2 = serializer.deserialize<SQL::Value>();
|
2021-07-17 11:02:28 +00:00
|
|
|
EXPECT_EQ(v2.type(), SQL::SQLType::Tuple);
|
|
|
|
EXPECT_EQ(v, v2);
|
|
|
|
}
|
|
|
|
|
2021-06-17 17:23:52 +00: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 17:47:08 +00:00
|
|
|
NonnullRefPtr<SQL::TupleDescriptor> descriptor = adopt_ref(*new SQL::TupleDescriptor);
|
2021-11-02 20:39:00 +00: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 17:23:52 +00: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 17:48:02 +00:00
|
|
|
EXPECT_EQ(tuple[0], "Test"sv);
|
|
|
|
EXPECT_EQ(tuple[1], 42);
|
2021-06-17 17:23:52 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
TEST_CASE(serialize_tuple)
|
|
|
|
{
|
2021-07-13 17:47:08 +00:00
|
|
|
NonnullRefPtr<SQL::TupleDescriptor> descriptor = adopt_ref(*new SQL::TupleDescriptor);
|
2021-11-02 20:39:00 +00: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 17:23:52 +00: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 17:48:02 +00:00
|
|
|
EXPECT_EQ(tuple[0], "Test"sv);
|
2022-09-22 12:35:47 +00:00
|
|
|
EXPECT_EQ(tuple[1], 42);
|
2021-06-17 17:23:52 +00:00
|
|
|
|
2021-08-19 00:50:13 +00: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 17:48:02 +00:00
|
|
|
EXPECT_EQ(tuple2[0], "Test"sv);
|
|
|
|
EXPECT_EQ(tuple2[1], 42);
|
2021-06-17 17:23:52 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
TEST_CASE(copy_tuple)
|
|
|
|
{
|
2021-07-13 17:47:08 +00:00
|
|
|
NonnullRefPtr<SQL::TupleDescriptor> descriptor = adopt_ref(*new SQL::TupleDescriptor);
|
2021-11-02 20:39:00 +00: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 17:23:52 +00: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 17:48:02 +00:00
|
|
|
EXPECT_EQ(tuple, copy);
|
2021-06-17 17:23:52 +00: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 17:48:02 +00:00
|
|
|
EXPECT_EQ(tuple, copy_2);
|
2021-06-17 17:23:52 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
TEST_CASE(compare_tuples)
|
|
|
|
{
|
2021-07-13 17:47:08 +00:00
|
|
|
NonnullRefPtr<SQL::TupleDescriptor> descriptor = adopt_ref(*new SQL::TupleDescriptor);
|
2021-11-02 20:39:00 +00: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 17:23:52 +00: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);
|
|
|
|
}
|
LibSQL: Support 64-bit integer values and handle overflow errors
Currently, integers are stored in LibSQL as 32-bit signed integers, even
if the provided type is unsigned. This resulted in a series of unchecked
unsigned-to-signed conversions, and prevented storing 64-bit values.
Further, mathematical operations were performed without similar checks,
and without checking for overflow.
This changes SQL::Value to behave like SQLite for INTEGER types. In
SQLite, the INTEGER type does not imply a size or signedness of the
underlying type. Instead, SQLite determines on-the-fly what type is
needed as values are created and updated.
To do so, the SQL::Value variant can now hold an i64 or u64 integer. If
a specific type is requested, invalid conversions are now explictly an
error (e.g. converting a stored -1 to a u64 will fail). When binary
mathematical operations are performed, we now try to coerce the RHS
value to a type that works with the LHS value, failing the operation if
that isn't possible. Any overflow or invalid operation (e.g. bitshifting
a 64-bit value by more than 64 bytes) is an error.
2022-12-11 16:44:11 +00:00
|
|
|
|
|
|
|
TEST_CASE(add)
|
|
|
|
{
|
|
|
|
{
|
|
|
|
SQL::Value value1 { 21 };
|
|
|
|
SQL::Value value2 { 42 };
|
|
|
|
|
|
|
|
auto result = value1.add(value2);
|
|
|
|
EXPECT_EQ(result.value().type(), SQL::SQLType::Integer);
|
|
|
|
EXPECT_EQ(result.value(), 63);
|
|
|
|
}
|
|
|
|
{
|
|
|
|
SQL::Value value1 { 21 };
|
|
|
|
SQL::Value value2 { static_cast<u8>(42) };
|
|
|
|
|
|
|
|
auto result = value1.add(value2);
|
|
|
|
EXPECT_EQ(result.value().type(), SQL::SQLType::Integer);
|
|
|
|
EXPECT_EQ(result.value(), 63);
|
|
|
|
}
|
|
|
|
{
|
|
|
|
SQL::Value value1 { static_cast<u8>(21) };
|
|
|
|
SQL::Value value2 { 42 };
|
|
|
|
|
|
|
|
auto result = value1.add(value2);
|
|
|
|
EXPECT_EQ(result.value().type(), SQL::SQLType::Integer);
|
|
|
|
EXPECT_EQ(result.value(), 63);
|
|
|
|
}
|
|
|
|
{
|
|
|
|
SQL::Value value1 { static_cast<double>(21) };
|
|
|
|
SQL::Value value2 { 42 };
|
|
|
|
|
|
|
|
auto result = value1.add(value2);
|
|
|
|
EXPECT_EQ(result.value().type(), SQL::SQLType::Integer);
|
|
|
|
EXPECT_EQ(result.value(), 63);
|
|
|
|
}
|
|
|
|
{
|
|
|
|
SQL::Value value1 { static_cast<double>(21.5) };
|
|
|
|
SQL::Value value2 { 42 };
|
|
|
|
|
|
|
|
auto result = value1.add(value2);
|
|
|
|
EXPECT_EQ(result.value().type(), SQL::SQLType::Float);
|
|
|
|
EXPECT((result.value().to_double().value() - 63.5) < NumericLimits<double>().epsilon());
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
TEST_CASE(add_error)
|
|
|
|
{
|
|
|
|
{
|
|
|
|
// Fails to coerce value2 to the signedness of value1.
|
|
|
|
SQL::Value value1 { 1 };
|
|
|
|
SQL::Value value2 { NumericLimits<u64>::max() };
|
|
|
|
|
|
|
|
auto result = value1.add(value2);
|
|
|
|
EXPECT(result.is_error());
|
|
|
|
EXPECT_EQ(result.error().error(), SQL::SQLErrorCode::IntegerOverflow);
|
|
|
|
}
|
|
|
|
{
|
|
|
|
// Fails to coerce value2 to the signedness of value1.
|
|
|
|
SQL::Value value1 { static_cast<u64>(1) };
|
|
|
|
SQL::Value value2 { -1 };
|
|
|
|
|
|
|
|
auto result = value1.add(value2);
|
|
|
|
EXPECT(result.is_error());
|
|
|
|
EXPECT_EQ(result.error().error(), SQL::SQLErrorCode::IntegerOverflow);
|
|
|
|
}
|
|
|
|
{
|
|
|
|
// The operation itself would overflow.
|
|
|
|
SQL::Value value1 { static_cast<u64>(1) };
|
|
|
|
SQL::Value value2 { NumericLimits<u64>::max() };
|
|
|
|
|
|
|
|
auto result = value1.add(value2);
|
|
|
|
EXPECT(result.is_error());
|
|
|
|
EXPECT_EQ(result.error().error(), SQL::SQLErrorCode::IntegerOverflow);
|
|
|
|
}
|
|
|
|
{
|
|
|
|
// Cannot convert value to a number.
|
|
|
|
SQL::Value value1 { 1 };
|
|
|
|
SQL::Value value2 { "foo"sv };
|
|
|
|
|
|
|
|
auto result = value1.add(value2);
|
|
|
|
EXPECT(result.is_error());
|
|
|
|
EXPECT_EQ(result.error().error(), SQL::SQLErrorCode::NumericOperatorTypeMismatch);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
TEST_CASE(subtract)
|
|
|
|
{
|
|
|
|
{
|
|
|
|
SQL::Value value1 { 21 };
|
|
|
|
SQL::Value value2 { 42 };
|
|
|
|
|
|
|
|
auto result = value1.subtract(value2);
|
|
|
|
EXPECT_EQ(result.value().type(), SQL::SQLType::Integer);
|
|
|
|
EXPECT_EQ(result.value(), -21);
|
|
|
|
}
|
|
|
|
{
|
|
|
|
SQL::Value value1 { 21 };
|
|
|
|
SQL::Value value2 { static_cast<u8>(42) };
|
|
|
|
|
|
|
|
auto result = value1.subtract(value2);
|
|
|
|
EXPECT_EQ(result.value().type(), SQL::SQLType::Integer);
|
|
|
|
EXPECT_EQ(result.value(), -21);
|
|
|
|
}
|
|
|
|
{
|
|
|
|
SQL::Value value1 { static_cast<u8>(42) };
|
|
|
|
SQL::Value value2 { 21 };
|
|
|
|
|
|
|
|
auto result = value1.subtract(value2);
|
|
|
|
EXPECT_EQ(result.value().type(), SQL::SQLType::Integer);
|
|
|
|
EXPECT_EQ(result.value(), 21);
|
|
|
|
}
|
|
|
|
{
|
|
|
|
SQL::Value value1 { static_cast<double>(21) };
|
|
|
|
SQL::Value value2 { 42 };
|
|
|
|
|
|
|
|
auto result = value1.subtract(value2);
|
|
|
|
EXPECT_EQ(result.value().type(), SQL::SQLType::Integer);
|
|
|
|
EXPECT_EQ(result.value(), -21);
|
|
|
|
}
|
|
|
|
{
|
|
|
|
SQL::Value value1 { static_cast<double>(21.5) };
|
|
|
|
SQL::Value value2 { 42 };
|
|
|
|
|
|
|
|
auto result = value1.subtract(value2);
|
|
|
|
EXPECT_EQ(result.value().type(), SQL::SQLType::Float);
|
|
|
|
EXPECT((result.value().to_double().value() - 20.5) < NumericLimits<double>().epsilon());
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
TEST_CASE(subtract_error)
|
|
|
|
{
|
|
|
|
{
|
|
|
|
// Fails to coerce value2 to the signedness of value1.
|
|
|
|
SQL::Value value1 { 1 };
|
|
|
|
SQL::Value value2 { NumericLimits<u64>::max() };
|
|
|
|
|
|
|
|
auto result = value1.subtract(value2);
|
|
|
|
EXPECT(result.is_error());
|
|
|
|
EXPECT_EQ(result.error().error(), SQL::SQLErrorCode::IntegerOverflow);
|
|
|
|
}
|
|
|
|
{
|
|
|
|
// Fails to coerce value2 to the signedness of value1.
|
|
|
|
SQL::Value value1 { static_cast<u64>(1) };
|
|
|
|
SQL::Value value2 { -1 };
|
|
|
|
|
|
|
|
auto result = value1.subtract(value2);
|
|
|
|
EXPECT(result.is_error());
|
|
|
|
EXPECT_EQ(result.error().error(), SQL::SQLErrorCode::IntegerOverflow);
|
|
|
|
}
|
|
|
|
{
|
|
|
|
// The operation itself would overflow.
|
|
|
|
SQL::Value value1 { static_cast<u64>(0) };
|
|
|
|
SQL::Value value2 { static_cast<u64>(1) };
|
|
|
|
|
|
|
|
auto result = value1.subtract(value2);
|
|
|
|
EXPECT(result.is_error());
|
|
|
|
EXPECT_EQ(result.error().error(), SQL::SQLErrorCode::IntegerOverflow);
|
|
|
|
}
|
|
|
|
{
|
|
|
|
// Cannot convert value to a number.
|
|
|
|
SQL::Value value1 { 1 };
|
|
|
|
SQL::Value value2 { "foo"sv };
|
|
|
|
|
|
|
|
auto result = value1.subtract(value2);
|
|
|
|
EXPECT(result.is_error());
|
|
|
|
EXPECT_EQ(result.error().error(), SQL::SQLErrorCode::NumericOperatorTypeMismatch);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
TEST_CASE(multiply)
|
|
|
|
{
|
|
|
|
{
|
|
|
|
SQL::Value value1 { 2 };
|
|
|
|
SQL::Value value2 { 21 };
|
|
|
|
|
|
|
|
auto result = value1.multiply(value2);
|
|
|
|
EXPECT_EQ(result.value().type(), SQL::SQLType::Integer);
|
|
|
|
EXPECT_EQ(result.value(), 42);
|
|
|
|
}
|
|
|
|
{
|
|
|
|
SQL::Value value1 { 2 };
|
|
|
|
SQL::Value value2 { static_cast<u8>(21) };
|
|
|
|
|
|
|
|
auto result = value1.multiply(value2);
|
|
|
|
EXPECT_EQ(result.value().type(), SQL::SQLType::Integer);
|
|
|
|
EXPECT_EQ(result.value(), 42);
|
|
|
|
}
|
|
|
|
{
|
|
|
|
SQL::Value value1 { static_cast<u8>(2) };
|
|
|
|
SQL::Value value2 { 21 };
|
|
|
|
|
|
|
|
auto result = value1.multiply(value2);
|
|
|
|
EXPECT_EQ(result.value().type(), SQL::SQLType::Integer);
|
|
|
|
EXPECT_EQ(result.value(), 42);
|
|
|
|
}
|
|
|
|
{
|
|
|
|
SQL::Value value1 { static_cast<double>(2) };
|
|
|
|
SQL::Value value2 { 21 };
|
|
|
|
|
|
|
|
auto result = value1.multiply(value2);
|
|
|
|
EXPECT_EQ(result.value().type(), SQL::SQLType::Integer);
|
|
|
|
EXPECT_EQ(result.value(), 42);
|
|
|
|
}
|
|
|
|
{
|
|
|
|
SQL::Value value1 { static_cast<double>(2.5) };
|
|
|
|
SQL::Value value2 { 21 };
|
|
|
|
|
|
|
|
auto result = value1.multiply(value2);
|
|
|
|
EXPECT_EQ(result.value().type(), SQL::SQLType::Float);
|
|
|
|
EXPECT((result.value().to_double().value() - 52.5) < NumericLimits<double>().epsilon());
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
TEST_CASE(multiply_error)
|
|
|
|
{
|
|
|
|
{
|
|
|
|
// Fails to coerce value2 to the signedness of value1.
|
|
|
|
SQL::Value value1 { 1 };
|
|
|
|
SQL::Value value2 { NumericLimits<u64>::max() };
|
|
|
|
|
|
|
|
auto result = value1.multiply(value2);
|
|
|
|
EXPECT(result.is_error());
|
|
|
|
EXPECT_EQ(result.error().error(), SQL::SQLErrorCode::IntegerOverflow);
|
|
|
|
}
|
|
|
|
{
|
|
|
|
// Fails to coerce value2 to the signedness of value1.
|
|
|
|
SQL::Value value1 { static_cast<u64>(1) };
|
|
|
|
SQL::Value value2 { -1 };
|
|
|
|
|
|
|
|
auto result = value1.multiply(value2);
|
|
|
|
EXPECT(result.is_error());
|
|
|
|
EXPECT_EQ(result.error().error(), SQL::SQLErrorCode::IntegerOverflow);
|
|
|
|
}
|
|
|
|
{
|
|
|
|
// The operation itself would overflow.
|
|
|
|
SQL::Value value1 { NumericLimits<i64>::max() };
|
|
|
|
SQL::Value value2 { 2 };
|
|
|
|
|
|
|
|
auto result = value1.multiply(value2);
|
|
|
|
EXPECT(result.is_error());
|
|
|
|
EXPECT_EQ(result.error().error(), SQL::SQLErrorCode::IntegerOverflow);
|
|
|
|
}
|
|
|
|
{
|
|
|
|
// Cannot convert value to a number.
|
|
|
|
SQL::Value value1 { 1 };
|
|
|
|
SQL::Value value2 { "foo"sv };
|
|
|
|
|
|
|
|
auto result = value1.multiply(value2);
|
|
|
|
EXPECT(result.is_error());
|
|
|
|
EXPECT_EQ(result.error().error(), SQL::SQLErrorCode::NumericOperatorTypeMismatch);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
TEST_CASE(divide)
|
|
|
|
{
|
|
|
|
{
|
|
|
|
SQL::Value value1 { 42 };
|
|
|
|
SQL::Value value2 { -2 };
|
|
|
|
|
|
|
|
auto result = value1.divide(value2);
|
|
|
|
EXPECT_EQ(result.value().type(), SQL::SQLType::Integer);
|
|
|
|
EXPECT_EQ(result.value(), -21);
|
|
|
|
}
|
|
|
|
{
|
|
|
|
SQL::Value value1 { 42 };
|
|
|
|
SQL::Value value2 { static_cast<u8>(2) };
|
|
|
|
|
|
|
|
auto result = value1.divide(value2);
|
|
|
|
EXPECT_EQ(result.value().type(), SQL::SQLType::Integer);
|
|
|
|
EXPECT_EQ(result.value(), 21);
|
|
|
|
}
|
|
|
|
{
|
|
|
|
SQL::Value value1 { static_cast<u8>(42) };
|
|
|
|
SQL::Value value2 { 2 };
|
|
|
|
|
|
|
|
auto result = value1.divide(value2);
|
|
|
|
EXPECT_EQ(result.value().type(), SQL::SQLType::Integer);
|
|
|
|
EXPECT_EQ(result.value(), 21);
|
|
|
|
}
|
|
|
|
{
|
|
|
|
SQL::Value value1 { static_cast<double>(42) };
|
|
|
|
SQL::Value value2 { 2 };
|
|
|
|
|
|
|
|
auto result = value1.divide(value2);
|
|
|
|
EXPECT_EQ(result.value().type(), SQL::SQLType::Integer);
|
|
|
|
EXPECT_EQ(result.value(), 21);
|
|
|
|
}
|
|
|
|
{
|
|
|
|
SQL::Value value1 { static_cast<double>(43) };
|
|
|
|
SQL::Value value2 { 2 };
|
|
|
|
|
|
|
|
auto result = value1.divide(value2);
|
|
|
|
EXPECT_EQ(result.value().type(), SQL::SQLType::Float);
|
|
|
|
EXPECT((result.value().to_double().value() - 21.5) < NumericLimits<double>().epsilon());
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
TEST_CASE(divide_error)
|
|
|
|
{
|
|
|
|
{
|
|
|
|
// The operation itself would overflow.
|
|
|
|
SQL::Value value1 { 1 };
|
|
|
|
SQL::Value value2 { 0 };
|
|
|
|
|
|
|
|
auto result = value1.divide(value2);
|
|
|
|
EXPECT(result.is_error());
|
|
|
|
EXPECT_EQ(result.error().error(), SQL::SQLErrorCode::IntegerOverflow);
|
|
|
|
}
|
|
|
|
{
|
|
|
|
// Cannot convert value to a number.
|
|
|
|
SQL::Value value1 { 1 };
|
|
|
|
SQL::Value value2 { "foo"sv };
|
|
|
|
|
|
|
|
auto result = value1.divide(value2);
|
|
|
|
EXPECT(result.is_error());
|
|
|
|
EXPECT_EQ(result.error().error(), SQL::SQLErrorCode::NumericOperatorTypeMismatch);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
TEST_CASE(modulo)
|
|
|
|
{
|
|
|
|
{
|
|
|
|
SQL::Value value1 { 21 };
|
|
|
|
SQL::Value value2 { 2 };
|
|
|
|
|
|
|
|
auto result = value1.modulo(value2);
|
|
|
|
EXPECT_EQ(result.value().type(), SQL::SQLType::Integer);
|
|
|
|
EXPECT_EQ(result.value(), 1);
|
|
|
|
}
|
|
|
|
{
|
|
|
|
SQL::Value value1 { 21 };
|
|
|
|
SQL::Value value2 { static_cast<u8>(2) };
|
|
|
|
|
|
|
|
auto result = value1.modulo(value2);
|
|
|
|
EXPECT_EQ(result.value().type(), SQL::SQLType::Integer);
|
|
|
|
EXPECT_EQ(result.value(), 1);
|
|
|
|
}
|
|
|
|
{
|
|
|
|
SQL::Value value1 { static_cast<u8>(21) };
|
|
|
|
SQL::Value value2 { 2 };
|
|
|
|
|
|
|
|
auto result = value1.modulo(value2);
|
|
|
|
EXPECT_EQ(result.value().type(), SQL::SQLType::Integer);
|
|
|
|
EXPECT_EQ(result.value(), 1);
|
|
|
|
}
|
|
|
|
{
|
|
|
|
SQL::Value value1 { static_cast<double>(21) };
|
|
|
|
SQL::Value value2 { 2 };
|
|
|
|
|
|
|
|
auto result = value1.modulo(value2);
|
|
|
|
EXPECT_EQ(result.value().type(), SQL::SQLType::Integer);
|
|
|
|
EXPECT_EQ(result.value(), 1);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
TEST_CASE(modulo_error)
|
|
|
|
{
|
|
|
|
{
|
|
|
|
// Fails to coerce value2 to the signedness of value1.
|
|
|
|
SQL::Value value1 { 1 };
|
|
|
|
SQL::Value value2 { NumericLimits<u64>::max() };
|
|
|
|
|
|
|
|
auto result = value1.modulo(value2);
|
|
|
|
EXPECT(result.is_error());
|
|
|
|
EXPECT_EQ(result.error().error(), SQL::SQLErrorCode::IntegerOverflow);
|
|
|
|
}
|
|
|
|
{
|
|
|
|
// Fails to coerce value2 to the signedness of value1.
|
|
|
|
SQL::Value value1 { static_cast<u64>(1) };
|
|
|
|
SQL::Value value2 { -1 };
|
|
|
|
|
|
|
|
auto result = value1.modulo(value2);
|
|
|
|
EXPECT(result.is_error());
|
|
|
|
EXPECT_EQ(result.error().error(), SQL::SQLErrorCode::IntegerOverflow);
|
|
|
|
}
|
|
|
|
{
|
|
|
|
// The operation itself would overflow.
|
|
|
|
SQL::Value value1 { 21 };
|
|
|
|
SQL::Value value2 { 0 };
|
|
|
|
|
|
|
|
auto result = value1.modulo(value2);
|
|
|
|
EXPECT(result.is_error());
|
|
|
|
EXPECT_EQ(result.error().error(), SQL::SQLErrorCode::IntegerOverflow);
|
|
|
|
}
|
|
|
|
{
|
|
|
|
// Cannot convert value to an integer.
|
|
|
|
SQL::Value value1 { 1 };
|
|
|
|
SQL::Value value2 { "foo"sv };
|
|
|
|
|
|
|
|
auto result = value1.modulo(value2);
|
|
|
|
EXPECT(result.is_error());
|
|
|
|
EXPECT_EQ(result.error().error(), SQL::SQLErrorCode::NumericOperatorTypeMismatch);
|
|
|
|
}
|
|
|
|
{
|
|
|
|
// Cannot convert value to an integer.
|
|
|
|
SQL::Value value1 { static_cast<double>(21.5) };
|
|
|
|
SQL::Value value2 { 2 };
|
|
|
|
|
|
|
|
auto result = value1.modulo(value2);
|
|
|
|
EXPECT(result.is_error());
|
|
|
|
EXPECT_EQ(result.error().error(), SQL::SQLErrorCode::NumericOperatorTypeMismatch);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
TEST_CASE(shift_left)
|
|
|
|
{
|
|
|
|
{
|
|
|
|
SQL::Value value1 { 0b0011'0000 };
|
|
|
|
SQL::Value value2 { 2 };
|
|
|
|
|
|
|
|
auto result = value1.shift_left(value2);
|
|
|
|
EXPECT_EQ(result.value().type(), SQL::SQLType::Integer);
|
|
|
|
EXPECT_EQ(result.value(), 0b1100'0000);
|
|
|
|
}
|
|
|
|
{
|
|
|
|
SQL::Value value1 { 0b0011'0000 };
|
|
|
|
SQL::Value value2 { static_cast<u8>(2) };
|
|
|
|
|
|
|
|
auto result = value1.shift_left(value2);
|
|
|
|
EXPECT_EQ(result.value().type(), SQL::SQLType::Integer);
|
|
|
|
EXPECT_EQ(result.value(), 0b1100'0000);
|
|
|
|
}
|
|
|
|
{
|
|
|
|
SQL::Value value1 { static_cast<u8>(0b0011'0000) };
|
|
|
|
SQL::Value value2 { 2 };
|
|
|
|
|
|
|
|
auto result = value1.shift_left(value2);
|
|
|
|
EXPECT_EQ(result.value().type(), SQL::SQLType::Integer);
|
|
|
|
EXPECT_EQ(result.value(), 0b1100'0000);
|
|
|
|
}
|
|
|
|
{
|
|
|
|
SQL::Value value1 { static_cast<double>(0b0011'0000) };
|
|
|
|
SQL::Value value2 { 2 };
|
|
|
|
|
|
|
|
auto result = value1.shift_left(value2);
|
|
|
|
EXPECT_EQ(result.value().type(), SQL::SQLType::Integer);
|
|
|
|
EXPECT_EQ(result.value(), 0b1100'0000);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
TEST_CASE(shift_left_error)
|
|
|
|
{
|
|
|
|
{
|
|
|
|
// Fails to coerce value2 to the signedness of value1.
|
|
|
|
SQL::Value value1 { 1 };
|
|
|
|
SQL::Value value2 { NumericLimits<u64>::max() };
|
|
|
|
|
|
|
|
auto result = value1.shift_left(value2);
|
|
|
|
EXPECT(result.is_error());
|
|
|
|
EXPECT_EQ(result.error().error(), SQL::SQLErrorCode::IntegerOverflow);
|
|
|
|
}
|
|
|
|
{
|
|
|
|
// Fails to coerce value2 to the signedness of value1.
|
|
|
|
SQL::Value value1 { static_cast<u64>(1) };
|
|
|
|
SQL::Value value2 { -1 };
|
|
|
|
|
|
|
|
auto result = value1.shift_left(value2);
|
|
|
|
EXPECT(result.is_error());
|
|
|
|
EXPECT_EQ(result.error().error(), SQL::SQLErrorCode::IntegerOverflow);
|
|
|
|
}
|
|
|
|
{
|
|
|
|
// The operation itself would overflow.
|
|
|
|
SQL::Value value1 { 21 };
|
|
|
|
SQL::Value value2 { -1 };
|
|
|
|
|
|
|
|
auto result = value1.shift_left(value2);
|
|
|
|
EXPECT(result.is_error());
|
|
|
|
EXPECT_EQ(result.error().error(), SQL::SQLErrorCode::IntegerOverflow);
|
|
|
|
}
|
|
|
|
{
|
|
|
|
// The operation itself would overflow.
|
|
|
|
SQL::Value value1 { 21 };
|
|
|
|
SQL::Value value2 { 64 };
|
|
|
|
|
|
|
|
auto result = value1.shift_left(value2);
|
|
|
|
EXPECT(result.is_error());
|
|
|
|
EXPECT_EQ(result.error().error(), SQL::SQLErrorCode::IntegerOverflow);
|
|
|
|
}
|
|
|
|
{
|
|
|
|
// Cannot convert value to an integer.
|
|
|
|
SQL::Value value1 { 1 };
|
|
|
|
SQL::Value value2 { "foo"sv };
|
|
|
|
|
|
|
|
auto result = value1.shift_left(value2);
|
|
|
|
EXPECT(result.is_error());
|
|
|
|
EXPECT_EQ(result.error().error(), SQL::SQLErrorCode::NumericOperatorTypeMismatch);
|
|
|
|
}
|
|
|
|
{
|
|
|
|
// Cannot convert value to an integer.
|
|
|
|
SQL::Value value1 { static_cast<double>(21.5) };
|
|
|
|
SQL::Value value2 { 2 };
|
|
|
|
|
|
|
|
auto result = value1.shift_left(value2);
|
|
|
|
EXPECT(result.is_error());
|
|
|
|
EXPECT_EQ(result.error().error(), SQL::SQLErrorCode::NumericOperatorTypeMismatch);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
TEST_CASE(shift_right)
|
|
|
|
{
|
|
|
|
{
|
|
|
|
SQL::Value value1 { 0b0011'0000 };
|
|
|
|
SQL::Value value2 { 2 };
|
|
|
|
|
|
|
|
auto result = value1.shift_right(value2);
|
|
|
|
EXPECT_EQ(result.value().type(), SQL::SQLType::Integer);
|
|
|
|
EXPECT_EQ(result.value(), 0b0000'1100);
|
|
|
|
}
|
|
|
|
{
|
|
|
|
SQL::Value value1 { 0b0011'0000 };
|
|
|
|
SQL::Value value2 { static_cast<u8>(2) };
|
|
|
|
|
|
|
|
auto result = value1.shift_right(value2);
|
|
|
|
EXPECT_EQ(result.value().type(), SQL::SQLType::Integer);
|
|
|
|
EXPECT_EQ(result.value(), 0b0000'1100);
|
|
|
|
}
|
|
|
|
{
|
|
|
|
SQL::Value value1 { static_cast<u8>(0b0011'0000) };
|
|
|
|
SQL::Value value2 { 2 };
|
|
|
|
|
|
|
|
auto result = value1.shift_right(value2);
|
|
|
|
EXPECT_EQ(result.value().type(), SQL::SQLType::Integer);
|
|
|
|
EXPECT_EQ(result.value(), 0b0000'1100);
|
|
|
|
}
|
|
|
|
{
|
|
|
|
SQL::Value value1 { static_cast<double>(0b0011'0000) };
|
|
|
|
SQL::Value value2 { 2 };
|
|
|
|
|
|
|
|
auto result = value1.shift_right(value2);
|
|
|
|
EXPECT_EQ(result.value().type(), SQL::SQLType::Integer);
|
|
|
|
EXPECT_EQ(result.value(), 0b0000'1100);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
TEST_CASE(shift_right_error)
|
|
|
|
{
|
|
|
|
{
|
|
|
|
// Fails to coerce value2 to the signedness of value1.
|
|
|
|
SQL::Value value1 { 1 };
|
|
|
|
SQL::Value value2 { NumericLimits<u64>::max() };
|
|
|
|
|
|
|
|
auto result = value1.shift_right(value2);
|
|
|
|
EXPECT(result.is_error());
|
|
|
|
EXPECT_EQ(result.error().error(), SQL::SQLErrorCode::IntegerOverflow);
|
|
|
|
}
|
|
|
|
{
|
|
|
|
// Fails to coerce value2 to the signedness of value1.
|
|
|
|
SQL::Value value1 { static_cast<u64>(1) };
|
|
|
|
SQL::Value value2 { -1 };
|
|
|
|
|
|
|
|
auto result = value1.shift_right(value2);
|
|
|
|
EXPECT(result.is_error());
|
|
|
|
EXPECT_EQ(result.error().error(), SQL::SQLErrorCode::IntegerOverflow);
|
|
|
|
}
|
|
|
|
{
|
|
|
|
// The operation itself would overflow.
|
|
|
|
SQL::Value value1 { 21 };
|
|
|
|
SQL::Value value2 { -1 };
|
|
|
|
|
|
|
|
auto result = value1.shift_right(value2);
|
|
|
|
EXPECT(result.is_error());
|
|
|
|
EXPECT_EQ(result.error().error(), SQL::SQLErrorCode::IntegerOverflow);
|
|
|
|
}
|
|
|
|
{
|
|
|
|
// The operation itself would overflow.
|
|
|
|
SQL::Value value1 { 21 };
|
|
|
|
SQL::Value value2 { 64 };
|
|
|
|
|
|
|
|
auto result = value1.shift_right(value2);
|
|
|
|
EXPECT(result.is_error());
|
|
|
|
EXPECT_EQ(result.error().error(), SQL::SQLErrorCode::IntegerOverflow);
|
|
|
|
}
|
|
|
|
{
|
|
|
|
// Cannot convert value to an integer.
|
|
|
|
SQL::Value value1 { 1 };
|
|
|
|
SQL::Value value2 { "foo"sv };
|
|
|
|
|
|
|
|
auto result = value1.shift_right(value2);
|
|
|
|
EXPECT(result.is_error());
|
|
|
|
EXPECT_EQ(result.error().error(), SQL::SQLErrorCode::NumericOperatorTypeMismatch);
|
|
|
|
}
|
|
|
|
{
|
|
|
|
// Cannot convert value to an integer.
|
|
|
|
SQL::Value value1 { static_cast<double>(21.5) };
|
|
|
|
SQL::Value value2 { 2 };
|
|
|
|
|
|
|
|
auto result = value1.shift_right(value2);
|
|
|
|
EXPECT(result.is_error());
|
|
|
|
EXPECT_EQ(result.error().error(), SQL::SQLErrorCode::NumericOperatorTypeMismatch);
|
|
|
|
}
|
|
|
|
}
|