2021-06-17 13:23:52 -04:00
|
|
|
/*
|
|
|
|
|
* Copyright (c) 2021, Jan de Visser <jan@de-visser.net>
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
* Copyright (c) 2022, Tim Flynn <trflynn89@serenityos.org>
|
2021-06-17 13:23:52 -04:00
|
|
|
*
|
|
|
|
|
* SPDX-License-Identifier: BSD-2-Clause
|
|
|
|
|
*/
|
|
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
#include <AK/NumericLimits.h>
|
2022-02-11 10:23:20 -05:00
|
|
|
#include <LibSQL/AST/AST.h>
|
2021-08-18 20:50:13 -04:00
|
|
|
#include <LibSQL/Serializer.h>
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
#include <LibSQL/TupleDescriptor.h>
|
2021-06-17 13:23:52 -04:00
|
|
|
#include <LibSQL/Value.h>
|
2021-07-17 07:02:28 -04:00
|
|
|
#include <math.h>
|
|
|
|
|
#include <string.h>
|
2021-06-17 13:23:52 -04:00
|
|
|
|
|
|
|
|
namespace SQL {
|
|
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
Value::Value(SQLType type)
|
|
|
|
|
: m_type(type)
|
2021-06-17 13:23:52 -04:00
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
2022-12-04 18:02:33 +00:00
|
|
|
Value::Value(DeprecatedString value)
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
: m_type(SQLType::Text)
|
|
|
|
|
, m_value(move(value))
|
2021-06-17 13:23:52 -04:00
|
|
|
{
|
2021-07-17 07:02:28 -04:00
|
|
|
}
|
|
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
Value::Value(int value)
|
|
|
|
|
: m_type(SQLType::Integer)
|
|
|
|
|
, m_value(value)
|
2021-07-17 07:02:28 -04:00
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
Value::Value(u32 value)
|
|
|
|
|
: m_type(SQLType::Integer)
|
|
|
|
|
, m_value(static_cast<int>(value)) // FIXME: Handle signed overflow.
|
2021-07-17 07:02:28 -04:00
|
|
|
{
|
2021-06-17 13:23:52 -04:00
|
|
|
}
|
|
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
Value::Value(double value)
|
|
|
|
|
: m_type(SQLType::Float)
|
|
|
|
|
, m_value(value)
|
2021-06-17 13:23:52 -04:00
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
Value::Value(NonnullRefPtr<TupleDescriptor> descriptor, Vector<Value> values)
|
|
|
|
|
: m_type(SQLType::Tuple)
|
|
|
|
|
, m_value(TupleValue { move(descriptor), move(values) })
|
2021-06-17 13:23:52 -04:00
|
|
|
{
|
2021-07-17 07:02:28 -04:00
|
|
|
}
|
|
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
Value::Value(Value const& other)
|
|
|
|
|
: m_type(other.m_type)
|
|
|
|
|
, m_value(other.m_value)
|
2021-07-17 07:02:28 -04:00
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
Value::Value(Value&& other)
|
|
|
|
|
: m_type(other.m_type)
|
|
|
|
|
, m_value(move(other.m_value))
|
2021-07-17 07:02:28 -04:00
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
Value::~Value() = default;
|
2021-07-17 07:02:28 -04:00
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
ResultOr<Value> Value::create_tuple(NonnullRefPtr<TupleDescriptor> descriptor)
|
2021-10-21 18:06:24 -04:00
|
|
|
{
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
Vector<Value> values;
|
|
|
|
|
TRY(values.try_resize(descriptor->size()));
|
2021-10-21 18:06:24 -04:00
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
for (size_t i = 0; i < descriptor->size(); ++i)
|
|
|
|
|
values[i].m_type = descriptor->at(i).type;
|
2021-07-17 07:02:28 -04:00
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
return Value { move(descriptor), move(values) };
|
2021-07-17 07:02:28 -04:00
|
|
|
}
|
|
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
ResultOr<Value> Value::create_tuple(Vector<Value> values)
|
2021-07-17 07:02:28 -04:00
|
|
|
{
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
auto descriptor = TRY(infer_tuple_descriptor(values));
|
|
|
|
|
return Value { move(descriptor), move(values) };
|
2021-07-17 07:02:28 -04:00
|
|
|
}
|
|
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
SQLType Value::type() const
|
2021-07-17 07:02:28 -04:00
|
|
|
{
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
return m_type;
|
2021-06-17 13:23:52 -04:00
|
|
|
}
|
|
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
StringView Value::type_name() const
|
2021-06-17 13:23:52 -04:00
|
|
|
{
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
switch (type()) {
|
|
|
|
|
#undef __ENUMERATE_SQL_TYPE
|
|
|
|
|
#define __ENUMERATE_SQL_TYPE(name, cardinal, type, impl, size) \
|
|
|
|
|
case SQLType::type: \
|
|
|
|
|
return name##sv;
|
|
|
|
|
ENUMERATE_SQL_TYPES(__ENUMERATE_SQL_TYPE)
|
|
|
|
|
#undef __ENUMERATE_SQL_TYPE
|
|
|
|
|
default:
|
|
|
|
|
VERIFY_NOT_REACHED();
|
|
|
|
|
}
|
2021-06-17 13:23:52 -04:00
|
|
|
}
|
|
|
|
|
|
2021-07-17 07:02:28 -04:00
|
|
|
bool Value::is_null() const
|
|
|
|
|
{
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
return !m_value.has_value();
|
2021-07-17 07:02:28 -04:00
|
|
|
}
|
|
|
|
|
|
2022-12-06 01:12:49 +00:00
|
|
|
DeprecatedString Value::to_deprecated_string() const
|
2021-07-17 07:02:28 -04:00
|
|
|
{
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
if (is_null())
|
|
|
|
|
return "(null)"sv;
|
2021-07-17 07:02:28 -04:00
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
return m_value->visit(
|
2022-12-04 18:02:33 +00:00
|
|
|
[](DeprecatedString const& value) -> DeprecatedString { return value; },
|
|
|
|
|
[](int value) -> DeprecatedString { return DeprecatedString::number(value); },
|
|
|
|
|
[](double value) -> DeprecatedString { return DeprecatedString::number(value); },
|
|
|
|
|
[](bool value) -> DeprecatedString { return value ? "true"sv : "false"sv; },
|
|
|
|
|
[](TupleValue const& value) -> DeprecatedString {
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
StringBuilder builder;
|
2021-07-17 07:02:28 -04:00
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
builder.append('(');
|
|
|
|
|
builder.join(',', value.values);
|
|
|
|
|
builder.append(')');
|
2021-07-17 07:02:28 -04:00
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
return builder.build();
|
|
|
|
|
});
|
2021-07-17 07:02:28 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
Optional<int> Value::to_int() const
|
|
|
|
|
{
|
|
|
|
|
if (is_null())
|
|
|
|
|
return {};
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
|
|
|
|
|
return m_value->visit(
|
2022-12-04 18:02:33 +00:00
|
|
|
[](DeprecatedString const& value) -> Optional<int> { return value.to_int(); },
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
[](int value) -> Optional<int> { return value; },
|
|
|
|
|
[](double value) -> Optional<int> {
|
|
|
|
|
if (value > static_cast<double>(NumericLimits<int>::max()))
|
|
|
|
|
return {};
|
|
|
|
|
if (value < static_cast<double>(NumericLimits<int>::min()))
|
|
|
|
|
return {};
|
|
|
|
|
return static_cast<int>(round(value));
|
|
|
|
|
},
|
|
|
|
|
[](bool value) -> Optional<int> { return static_cast<int>(value); },
|
|
|
|
|
[](TupleValue const&) -> Optional<int> { return {}; });
|
2021-07-17 07:02:28 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
Optional<u32> Value::to_u32() const
|
|
|
|
|
{
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
// FIXME: Handle negative values.
|
|
|
|
|
if (auto result = to_int(); result.has_value())
|
|
|
|
|
return static_cast<u32>(result.value());
|
2021-07-17 07:02:28 -04:00
|
|
|
return {};
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
Optional<double> Value::to_double() const
|
|
|
|
|
{
|
|
|
|
|
if (is_null())
|
|
|
|
|
return {};
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
|
|
|
|
|
return m_value->visit(
|
2022-12-04 18:02:33 +00:00
|
|
|
[](DeprecatedString const& value) -> Optional<double> {
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
char* end = nullptr;
|
|
|
|
|
double result = strtod(value.characters(), &end);
|
|
|
|
|
|
|
|
|
|
if (end == value.characters())
|
|
|
|
|
return {};
|
|
|
|
|
return result;
|
|
|
|
|
},
|
|
|
|
|
[](int value) -> Optional<double> { return static_cast<double>(value); },
|
|
|
|
|
[](double value) -> Optional<double> { return value; },
|
|
|
|
|
[](bool value) -> Optional<double> { return static_cast<double>(value); },
|
|
|
|
|
[](TupleValue const&) -> Optional<double> { return {}; });
|
2021-07-17 07:02:28 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
Optional<bool> Value::to_bool() const
|
|
|
|
|
{
|
|
|
|
|
if (is_null())
|
|
|
|
|
return {};
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
|
|
|
|
|
return m_value->visit(
|
2022-12-04 18:02:33 +00:00
|
|
|
[](DeprecatedString const& value) -> Optional<bool> {
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
if (value.equals_ignoring_case("true"sv) || value.equals_ignoring_case("t"sv))
|
|
|
|
|
return true;
|
|
|
|
|
if (value.equals_ignoring_case("false"sv) || value.equals_ignoring_case("f"sv))
|
|
|
|
|
return false;
|
|
|
|
|
return {};
|
|
|
|
|
},
|
|
|
|
|
[](int value) -> Optional<bool> { return static_cast<bool>(value); },
|
|
|
|
|
[](double value) -> Optional<bool> { return fabs(value) > NumericLimits<double>::epsilon(); },
|
|
|
|
|
[](bool value) -> Optional<bool> { return value; },
|
|
|
|
|
[](TupleValue const& value) -> Optional<bool> {
|
|
|
|
|
for (auto const& element : value.values) {
|
|
|
|
|
auto as_bool = element.to_bool();
|
|
|
|
|
if (!as_bool.has_value())
|
|
|
|
|
return {};
|
|
|
|
|
if (!as_bool.value())
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return true;
|
|
|
|
|
});
|
2021-07-17 07:02:28 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
Optional<Vector<Value>> Value::to_vector() const
|
|
|
|
|
{
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
if (is_null() || (type() != SQLType::Tuple))
|
2021-07-17 07:02:28 -04:00
|
|
|
return {};
|
|
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
auto const& tuple = m_value->get<TupleValue>();
|
|
|
|
|
return tuple.values;
|
2021-07-17 07:02:28 -04:00
|
|
|
}
|
|
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
Value& Value::operator=(Value value)
|
2021-07-17 07:02:28 -04:00
|
|
|
{
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
m_type = value.m_type;
|
|
|
|
|
m_value = move(value.m_value);
|
|
|
|
|
return *this;
|
2021-07-17 07:02:28 -04:00
|
|
|
}
|
|
|
|
|
|
2022-12-04 18:02:33 +00:00
|
|
|
Value& Value::operator=(DeprecatedString value)
|
2021-07-17 07:02:28 -04:00
|
|
|
{
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
m_type = SQLType::Text;
|
|
|
|
|
m_value = move(value);
|
|
|
|
|
return *this;
|
2021-07-17 07:02:28 -04:00
|
|
|
}
|
|
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
Value& Value::operator=(int value)
|
2021-10-21 18:06:24 -04:00
|
|
|
{
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
m_type = SQLType::Integer;
|
|
|
|
|
m_value = value;
|
|
|
|
|
return *this;
|
2021-10-21 18:06:24 -04:00
|
|
|
}
|
|
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
Value& Value::operator=(u32 value)
|
2021-07-17 07:02:28 -04:00
|
|
|
{
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
m_type = SQLType::Integer;
|
|
|
|
|
m_value = static_cast<int>(value); // FIXME: Handle signed overflow.
|
|
|
|
|
return *this;
|
2021-07-17 07:02:28 -04:00
|
|
|
}
|
|
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
Value& Value::operator=(double value)
|
2021-07-17 07:02:28 -04:00
|
|
|
{
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
m_type = SQLType::Float;
|
|
|
|
|
m_value = value;
|
|
|
|
|
return *this;
|
2021-07-17 07:02:28 -04:00
|
|
|
}
|
|
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
ResultOr<void> Value::assign_tuple(NonnullRefPtr<TupleDescriptor> descriptor)
|
2021-07-17 07:02:28 -04:00
|
|
|
{
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
Vector<Value> values;
|
|
|
|
|
TRY(values.try_resize(descriptor->size()));
|
2021-07-17 07:02:28 -04:00
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
for (size_t i = 0; i < descriptor->size(); ++i)
|
|
|
|
|
values[i].m_type = descriptor->at(i).type;
|
2021-06-17 13:23:52 -04:00
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
m_type = SQLType::Tuple;
|
|
|
|
|
m_value = TupleValue { move(descriptor), move(values) };
|
2021-07-17 07:02:28 -04:00
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
return {};
|
2021-06-17 13:23:52 -04:00
|
|
|
}
|
|
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
ResultOr<void> Value::assign_tuple(Vector<Value> values)
|
2021-06-17 13:23:52 -04:00
|
|
|
{
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
if (is_null() || (type() != SQLType::Tuple)) {
|
|
|
|
|
auto descriptor = TRY(infer_tuple_descriptor(values));
|
2021-06-17 13:23:52 -04:00
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
m_type = SQLType::Tuple;
|
|
|
|
|
m_value = TupleValue { move(descriptor), move(values) };
|
2021-06-17 13:23:52 -04:00
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
return {};
|
|
|
|
|
}
|
2021-06-17 13:23:52 -04:00
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
auto& tuple = m_value->get<TupleValue>();
|
2021-06-17 13:23:52 -04:00
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
if (values.size() > tuple.descriptor->size())
|
|
|
|
|
return Result { SQLCommand::Unknown, SQLErrorCode::InvalidNumberOfValues };
|
|
|
|
|
|
|
|
|
|
for (size_t i = 0; i < values.size(); ++i) {
|
|
|
|
|
if (values[i].type() != tuple.descriptor->at(i).type)
|
|
|
|
|
return Result { SQLCommand::Unknown, SQLErrorCode::InvalidType, SQLType_name(values[i].type()) };
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (values.size() < tuple.descriptor->size()) {
|
|
|
|
|
size_t original_size = values.size();
|
|
|
|
|
MUST(values.try_resize(tuple.descriptor->size()));
|
|
|
|
|
|
|
|
|
|
for (size_t i = original_size; i < values.size(); ++i)
|
|
|
|
|
values[i].m_type = tuple.descriptor->at(i).type;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
m_value = TupleValue { move(tuple.descriptor), move(values) };
|
|
|
|
|
return {};
|
2021-06-17 13:23:52 -04:00
|
|
|
}
|
|
|
|
|
|
2021-07-17 07:02:28 -04:00
|
|
|
size_t Value::length() const
|
2021-06-17 13:23:52 -04:00
|
|
|
{
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
if (is_null())
|
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
|
|
// FIXME: This seems to be more of an encoded byte size rather than a length.
|
|
|
|
|
return m_value->visit(
|
2022-12-04 18:02:33 +00:00
|
|
|
[](DeprecatedString const& value) -> size_t { return sizeof(u32) + value.length(); },
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
[](int value) -> size_t { return sizeof(value); },
|
|
|
|
|
[](double value) -> size_t { return sizeof(value); },
|
|
|
|
|
[](bool value) -> size_t { return sizeof(value); },
|
|
|
|
|
[](TupleValue const& value) -> size_t {
|
|
|
|
|
auto size = value.descriptor->length() + sizeof(u32);
|
|
|
|
|
|
|
|
|
|
for (auto const& element : value.values)
|
|
|
|
|
size += element.length();
|
|
|
|
|
|
|
|
|
|
return size;
|
|
|
|
|
});
|
2021-06-17 13:23:52 -04:00
|
|
|
}
|
|
|
|
|
|
2021-07-17 07:02:28 -04:00
|
|
|
u32 Value::hash() const
|
2021-06-17 13:23:52 -04:00
|
|
|
{
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
if (is_null())
|
|
|
|
|
return 0;
|
2021-07-17 07:02:28 -04:00
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
return m_value->visit(
|
2022-12-04 18:02:33 +00:00
|
|
|
[](DeprecatedString const& value) -> u32 { return value.hash(); },
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
[](int value) -> u32 { return int_hash(value); },
|
|
|
|
|
[](double) -> u32 { VERIFY_NOT_REACHED(); },
|
|
|
|
|
[](bool value) -> u32 { return int_hash(value); },
|
|
|
|
|
[](TupleValue const& value) -> u32 {
|
|
|
|
|
u32 hash = 0;
|
|
|
|
|
|
|
|
|
|
for (auto const& element : value.values) {
|
|
|
|
|
if (hash == 0)
|
|
|
|
|
hash = element.hash();
|
|
|
|
|
else
|
|
|
|
|
hash = pair_int_hash(hash, element.hash());
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return hash;
|
|
|
|
|
});
|
2021-07-17 07:02:28 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
int Value::compare(Value const& other) const
|
|
|
|
|
{
|
|
|
|
|
if (is_null())
|
|
|
|
|
return -1;
|
|
|
|
|
if (other.is_null())
|
|
|
|
|
return 1;
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
|
|
|
|
|
return m_value->visit(
|
2022-12-06 01:12:49 +00:00
|
|
|
[&](DeprecatedString const& value) -> int { return value.view().compare(other.to_deprecated_string()); },
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
[&](int value) -> int {
|
|
|
|
|
auto casted = other.to_int();
|
|
|
|
|
if (!casted.has_value())
|
|
|
|
|
return 1;
|
|
|
|
|
|
|
|
|
|
if (value == *casted)
|
|
|
|
|
return 0;
|
|
|
|
|
return value < *casted ? -1 : 1;
|
|
|
|
|
},
|
|
|
|
|
[&](double value) -> int {
|
|
|
|
|
auto casted = other.to_double();
|
|
|
|
|
if (!casted.has_value())
|
|
|
|
|
return 1;
|
|
|
|
|
|
|
|
|
|
auto diff = value - *casted;
|
|
|
|
|
if (fabs(diff) < NumericLimits<double>::epsilon())
|
|
|
|
|
return 0;
|
|
|
|
|
return diff < 0 ? -1 : 1;
|
|
|
|
|
},
|
|
|
|
|
[&](bool value) -> int {
|
|
|
|
|
auto casted = other.to_bool();
|
|
|
|
|
if (!casted.has_value())
|
|
|
|
|
return 1;
|
|
|
|
|
return value ^ *casted;
|
|
|
|
|
},
|
|
|
|
|
[&](TupleValue const& value) -> int {
|
|
|
|
|
if (other.is_null() || (other.type() != SQLType::Tuple)) {
|
|
|
|
|
if (value.values.size() == 1)
|
|
|
|
|
return value.values[0].compare(other);
|
|
|
|
|
return 1;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
auto const& other_value = other.m_value->get<TupleValue>();
|
|
|
|
|
if (auto result = value.descriptor->compare_ignoring_names(*other_value.descriptor); result != 0)
|
|
|
|
|
return 1;
|
|
|
|
|
|
|
|
|
|
if (value.values.size() != other_value.values.size())
|
|
|
|
|
return value.values.size() < other_value.values.size() ? -1 : 1;
|
|
|
|
|
|
|
|
|
|
for (size_t i = 0; i < value.values.size(); ++i) {
|
|
|
|
|
auto result = value.values[i].compare(other_value.values[i]);
|
|
|
|
|
if (result == 0)
|
|
|
|
|
continue;
|
|
|
|
|
|
|
|
|
|
if (value.descriptor->at(i).order == Order::Descending)
|
|
|
|
|
result = -result;
|
|
|
|
|
return result;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
});
|
2021-07-17 07:02:28 -04:00
|
|
|
}
|
|
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
bool Value::operator==(Value const& value) const
|
2021-07-17 07:02:28 -04:00
|
|
|
{
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
return compare(value) == 0;
|
2021-07-17 07:02:28 -04:00
|
|
|
}
|
|
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
bool Value::operator==(StringView value) const
|
2021-07-17 07:02:28 -04:00
|
|
|
{
|
2022-12-06 01:12:49 +00:00
|
|
|
return to_deprecated_string() == value;
|
2021-07-17 07:02:28 -04:00
|
|
|
}
|
|
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
bool Value::operator==(int value) const
|
2021-07-17 07:02:28 -04:00
|
|
|
{
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
return to_int() == value;
|
2021-07-17 07:02:28 -04:00
|
|
|
}
|
|
|
|
|
|
2022-11-28 07:45:51 -05:00
|
|
|
bool Value::operator==(u32 value) const
|
|
|
|
|
{
|
|
|
|
|
return to_u32() == value;
|
|
|
|
|
}
|
|
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
bool Value::operator==(double value) const
|
2021-07-17 07:02:28 -04:00
|
|
|
{
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
return to_double() == value;
|
2021-07-17 07:02:28 -04:00
|
|
|
}
|
|
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
bool Value::operator!=(Value const& value) const
|
2021-07-17 07:02:28 -04:00
|
|
|
{
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
return compare(value) != 0;
|
2021-07-17 07:02:28 -04:00
|
|
|
}
|
|
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
bool Value::operator<(Value const& value) const
|
2021-07-17 07:02:28 -04:00
|
|
|
{
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
return compare(value) < 0;
|
2021-07-17 07:02:28 -04:00
|
|
|
}
|
|
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
bool Value::operator<=(Value const& value) const
|
2021-07-17 07:02:28 -04:00
|
|
|
{
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
return compare(value) <= 0;
|
2021-07-17 07:02:28 -04:00
|
|
|
}
|
|
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
bool Value::operator>(Value const& value) const
|
2021-07-17 07:02:28 -04:00
|
|
|
{
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
return compare(value) > 0;
|
2021-07-17 07:02:28 -04:00
|
|
|
}
|
|
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
bool Value::operator>=(Value const& value) const
|
2021-07-17 07:02:28 -04:00
|
|
|
{
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
return compare(value) >= 0;
|
2021-07-17 07:02:28 -04:00
|
|
|
}
|
|
|
|
|
|
2022-02-11 10:23:20 -05:00
|
|
|
static Result invalid_type_for_numeric_operator(AST::BinaryOperator op)
|
|
|
|
|
{
|
|
|
|
|
return { SQLCommand::Unknown, SQLErrorCode::NumericOperatorTypeMismatch, BinaryOperator_name(op) };
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
ResultOr<Value> Value::add(Value const& other) const
|
2021-10-21 18:06:24 -04:00
|
|
|
{
|
|
|
|
|
if (auto double_maybe = to_double(); double_maybe.has_value()) {
|
|
|
|
|
if (auto other_double_maybe = other.to_double(); other_double_maybe.has_value())
|
|
|
|
|
return Value(double_maybe.value() + other_double_maybe.value());
|
|
|
|
|
if (auto int_maybe = other.to_int(); int_maybe.has_value())
|
|
|
|
|
return Value(double_maybe.value() + (double)int_maybe.value());
|
2022-02-11 10:23:20 -05:00
|
|
|
} else if (auto int_maybe = to_int(); int_maybe.has_value()) {
|
2021-10-21 18:06:24 -04:00
|
|
|
if (auto other_double_maybe = other.to_double(); other_double_maybe.has_value())
|
|
|
|
|
return Value(other_double_maybe.value() + (double)int_maybe.value());
|
|
|
|
|
if (auto other_int_maybe = other.to_int(); other_int_maybe.has_value())
|
|
|
|
|
return Value(int_maybe.value() + other_int_maybe.value());
|
|
|
|
|
}
|
2022-02-11 10:23:20 -05:00
|
|
|
return invalid_type_for_numeric_operator(AST::BinaryOperator::Plus);
|
2021-10-21 18:06:24 -04:00
|
|
|
}
|
|
|
|
|
|
2022-02-11 10:23:20 -05:00
|
|
|
ResultOr<Value> Value::subtract(Value const& other) const
|
2021-10-21 18:06:24 -04:00
|
|
|
{
|
|
|
|
|
if (auto double_maybe = to_double(); double_maybe.has_value()) {
|
|
|
|
|
if (auto other_double_maybe = other.to_double(); other_double_maybe.has_value())
|
|
|
|
|
return Value(double_maybe.value() - other_double_maybe.value());
|
|
|
|
|
if (auto int_maybe = other.to_int(); int_maybe.has_value())
|
|
|
|
|
return Value(double_maybe.value() - (double)int_maybe.value());
|
2022-02-11 10:23:20 -05:00
|
|
|
} else if (auto int_maybe = to_int(); int_maybe.has_value()) {
|
2021-10-21 18:06:24 -04:00
|
|
|
if (auto other_double_maybe = other.to_double(); other_double_maybe.has_value())
|
|
|
|
|
return Value((double)int_maybe.value() - other_double_maybe.value());
|
|
|
|
|
if (auto other_int_maybe = other.to_int(); other_int_maybe.has_value())
|
|
|
|
|
return Value(int_maybe.value() - other_int_maybe.value());
|
|
|
|
|
}
|
2022-02-11 10:23:20 -05:00
|
|
|
return invalid_type_for_numeric_operator(AST::BinaryOperator::Minus);
|
2021-10-21 18:06:24 -04:00
|
|
|
}
|
|
|
|
|
|
2022-02-11 10:23:20 -05:00
|
|
|
ResultOr<Value> Value::multiply(Value const& other) const
|
2021-10-21 18:06:24 -04:00
|
|
|
{
|
|
|
|
|
if (auto double_maybe = to_double(); double_maybe.has_value()) {
|
|
|
|
|
if (auto other_double_maybe = other.to_double(); other_double_maybe.has_value())
|
|
|
|
|
return Value(double_maybe.value() * other_double_maybe.value());
|
|
|
|
|
if (auto int_maybe = other.to_int(); int_maybe.has_value())
|
|
|
|
|
return Value(double_maybe.value() * (double)int_maybe.value());
|
2022-02-11 10:23:20 -05:00
|
|
|
} else if (auto int_maybe = to_int(); int_maybe.has_value()) {
|
2021-10-21 18:06:24 -04:00
|
|
|
if (auto other_double_maybe = other.to_double(); other_double_maybe.has_value())
|
|
|
|
|
return Value((double)int_maybe.value() * other_double_maybe.value());
|
|
|
|
|
if (auto other_int_maybe = other.to_int(); other_int_maybe.has_value())
|
|
|
|
|
return Value(int_maybe.value() * other_int_maybe.value());
|
|
|
|
|
}
|
2022-02-11 10:23:20 -05:00
|
|
|
return invalid_type_for_numeric_operator(AST::BinaryOperator::Multiplication);
|
2021-10-21 18:06:24 -04:00
|
|
|
}
|
|
|
|
|
|
2022-02-11 10:23:20 -05:00
|
|
|
ResultOr<Value> Value::divide(Value const& other) const
|
2021-10-21 18:06:24 -04:00
|
|
|
{
|
|
|
|
|
if (auto double_maybe = to_double(); double_maybe.has_value()) {
|
|
|
|
|
if (auto other_double_maybe = other.to_double(); other_double_maybe.has_value())
|
|
|
|
|
return Value(double_maybe.value() / other_double_maybe.value());
|
|
|
|
|
if (auto int_maybe = other.to_int(); int_maybe.has_value())
|
|
|
|
|
return Value(double_maybe.value() / (double)int_maybe.value());
|
2022-02-11 10:23:20 -05:00
|
|
|
} else if (auto int_maybe = to_int(); int_maybe.has_value()) {
|
2021-10-21 18:06:24 -04:00
|
|
|
if (auto other_double_maybe = other.to_double(); other_double_maybe.has_value())
|
|
|
|
|
return Value((double)int_maybe.value() / other_double_maybe.value());
|
|
|
|
|
if (auto other_int_maybe = other.to_int(); other_int_maybe.has_value())
|
|
|
|
|
return Value(int_maybe.value() / other_int_maybe.value());
|
|
|
|
|
}
|
2022-02-11 10:23:20 -05:00
|
|
|
return invalid_type_for_numeric_operator(AST::BinaryOperator::Division);
|
2021-10-21 18:06:24 -04:00
|
|
|
}
|
|
|
|
|
|
2022-02-11 10:23:20 -05:00
|
|
|
ResultOr<Value> Value::modulo(Value const& other) const
|
2021-10-21 18:06:24 -04:00
|
|
|
{
|
|
|
|
|
auto int_maybe_1 = to_int();
|
|
|
|
|
auto int_maybe_2 = other.to_int();
|
2022-02-11 10:23:20 -05:00
|
|
|
if (!int_maybe_1.has_value() || !int_maybe_2.has_value())
|
|
|
|
|
return invalid_type_for_numeric_operator(AST::BinaryOperator::Modulo);
|
2021-10-21 18:06:24 -04:00
|
|
|
return Value(int_maybe_1.value() % int_maybe_2.value());
|
|
|
|
|
}
|
|
|
|
|
|
2022-02-11 10:23:20 -05:00
|
|
|
ResultOr<Value> Value::shift_left(Value const& other) const
|
2021-10-21 18:06:24 -04:00
|
|
|
{
|
|
|
|
|
auto u32_maybe = to_u32();
|
|
|
|
|
auto num_bytes_maybe = other.to_int();
|
2022-02-11 10:23:20 -05:00
|
|
|
if (!u32_maybe.has_value() || !num_bytes_maybe.has_value())
|
|
|
|
|
return invalid_type_for_numeric_operator(AST::BinaryOperator::ShiftLeft);
|
2021-10-21 18:06:24 -04:00
|
|
|
return Value(u32_maybe.value() << num_bytes_maybe.value());
|
|
|
|
|
}
|
|
|
|
|
|
2022-02-11 10:23:20 -05:00
|
|
|
ResultOr<Value> Value::shift_right(Value const& other) const
|
2021-10-21 18:06:24 -04:00
|
|
|
{
|
|
|
|
|
auto u32_maybe = to_u32();
|
|
|
|
|
auto num_bytes_maybe = other.to_int();
|
2022-02-11 10:23:20 -05:00
|
|
|
if (!u32_maybe.has_value() || !num_bytes_maybe.has_value())
|
|
|
|
|
return invalid_type_for_numeric_operator(AST::BinaryOperator::ShiftRight);
|
2021-10-21 18:06:24 -04:00
|
|
|
return Value(u32_maybe.value() >> num_bytes_maybe.value());
|
|
|
|
|
}
|
|
|
|
|
|
2022-02-11 10:23:20 -05:00
|
|
|
ResultOr<Value> Value::bitwise_or(Value const& other) const
|
2021-10-21 18:06:24 -04:00
|
|
|
{
|
|
|
|
|
auto u32_maybe_1 = to_u32();
|
|
|
|
|
auto u32_maybe_2 = other.to_u32();
|
2022-02-11 10:23:20 -05:00
|
|
|
if (!u32_maybe_1.has_value() || !u32_maybe_2.has_value())
|
|
|
|
|
return invalid_type_for_numeric_operator(AST::BinaryOperator::BitwiseOr);
|
2021-10-21 18:06:24 -04:00
|
|
|
return Value(u32_maybe_1.value() | u32_maybe_2.value());
|
|
|
|
|
}
|
|
|
|
|
|
2022-02-11 10:23:20 -05:00
|
|
|
ResultOr<Value> Value::bitwise_and(Value const& other) const
|
2021-10-21 18:06:24 -04:00
|
|
|
{
|
|
|
|
|
auto u32_maybe_1 = to_u32();
|
|
|
|
|
auto u32_maybe_2 = other.to_u32();
|
2022-02-11 10:23:20 -05:00
|
|
|
if (!u32_maybe_1.has_value() || !u32_maybe_2.has_value())
|
|
|
|
|
return invalid_type_for_numeric_operator(AST::BinaryOperator::BitwiseAnd);
|
2021-10-21 18:06:24 -04:00
|
|
|
return Value(u32_maybe_1.value() & u32_maybe_2.value());
|
|
|
|
|
}
|
|
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
static constexpr auto sql_type_null_as_flag = static_cast<u8>(SQLType::Null);
|
|
|
|
|
|
2021-08-18 20:50:13 -04:00
|
|
|
void Value::serialize(Serializer& serializer) const
|
2021-07-17 07:02:28 -04:00
|
|
|
{
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
auto type_flags = static_cast<u8>(type());
|
2021-07-17 07:02:28 -04:00
|
|
|
if (is_null())
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
type_flags |= sql_type_null_as_flag;
|
2021-06-17 13:23:52 -04:00
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
serializer.serialize<u8>(type_flags);
|
2021-07-17 07:02:28 -04:00
|
|
|
|
|
|
|
|
if (is_null())
|
|
|
|
|
return;
|
|
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
m_value->visit(
|
|
|
|
|
[&](TupleValue const& value) {
|
|
|
|
|
serializer.serialize<TupleDescriptor>(*value.descriptor);
|
|
|
|
|
serializer.serialize(static_cast<u32>(value.values.size()));
|
2021-07-17 07:02:28 -04:00
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
for (auto const& element : value.values)
|
|
|
|
|
serializer.serialize<Value>(element);
|
|
|
|
|
},
|
|
|
|
|
[&](auto const& value) { serializer.serialize(value); });
|
2021-07-17 07:02:28 -04:00
|
|
|
}
|
|
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
void Value::deserialize(Serializer& serializer)
|
2021-07-17 07:02:28 -04:00
|
|
|
{
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
auto type_flags = serializer.deserialize<u8>();
|
|
|
|
|
bool has_value = true;
|
2021-07-17 07:02:28 -04:00
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
if ((type_flags & sql_type_null_as_flag) && (type_flags != sql_type_null_as_flag)) {
|
|
|
|
|
type_flags &= ~sql_type_null_as_flag;
|
|
|
|
|
has_value = false;
|
2021-07-17 07:02:28 -04:00
|
|
|
}
|
|
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
m_type = static_cast<SQLType>(type_flags);
|
2021-08-18 20:50:13 -04:00
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
if (!has_value)
|
2021-07-17 07:02:28 -04:00
|
|
|
return;
|
2022-02-11 09:43:02 -05:00
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
switch (m_type) {
|
|
|
|
|
case SQLType::Null:
|
|
|
|
|
VERIFY_NOT_REACHED();
|
|
|
|
|
break;
|
|
|
|
|
case SQLType::Text:
|
2022-12-04 18:02:33 +00:00
|
|
|
m_value = serializer.deserialize<DeprecatedString>();
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
break;
|
|
|
|
|
case SQLType::Integer:
|
|
|
|
|
m_value = serializer.deserialize<int>(0);
|
|
|
|
|
break;
|
|
|
|
|
case SQLType::Float:
|
|
|
|
|
m_value = serializer.deserialize<double>(0.0);
|
|
|
|
|
break;
|
|
|
|
|
case SQLType::Boolean:
|
|
|
|
|
m_value = serializer.deserialize<bool>(false);
|
|
|
|
|
break;
|
|
|
|
|
case SQLType::Tuple: {
|
|
|
|
|
auto descriptor = serializer.adopt_and_deserialize<TupleDescriptor>();
|
|
|
|
|
auto size = serializer.deserialize<u32>();
|
2021-06-17 13:23:52 -04:00
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
Vector<Value> values;
|
|
|
|
|
values.ensure_capacity(size);
|
2021-07-17 07:02:28 -04:00
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
for (size_t i = 0; i < size; ++i)
|
|
|
|
|
values.unchecked_append(serializer.deserialize<Value>());
|
2021-07-17 07:02:28 -04:00
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
m_value = TupleValue { move(descriptor), move(values) };
|
|
|
|
|
break;
|
2021-07-17 07:02:28 -04:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
TupleElementDescriptor Value::descriptor() const
|
2021-07-17 07:02:28 -04:00
|
|
|
{
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
return { "", "", "", type(), Order::Ascending };
|
2021-07-17 07:02:28 -04:00
|
|
|
}
|
|
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
ResultOr<NonnullRefPtr<TupleDescriptor>> Value::infer_tuple_descriptor(Vector<Value> const& values)
|
2021-07-17 07:02:28 -04:00
|
|
|
{
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
auto descriptor = TRY(adopt_nonnull_ref_or_enomem(new (nothrow) SQL::TupleDescriptor));
|
|
|
|
|
TRY(descriptor->try_ensure_capacity(values.size()));
|
2021-07-17 07:02:28 -04:00
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
for (auto const& element : values)
|
|
|
|
|
descriptor->unchecked_append({ ""sv, ""sv, ""sv, element.type(), Order::Ascending });
|
2021-06-17 13:23:52 -04:00
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
return descriptor;
|
2021-06-17 13:23:52 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
}
|