Stowage/ladybird
2
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-11-06 16:20:58 +00:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Userland/Libraries/LibSQL/Value.h

200 lines
5.6 KiB
C
Raw Normal View History

LibSQL: Basic dynamic value classes for SQL Storage layer This patch adds the basic dynamic value classes used by the SQL Storage layer. The most elementary class is Value, which holds a typed Value which can be converted to standard C++ types. A Tuple is a collection of Values described by a TupleDescriptor, which specifies the names, types, and ordering of the elements in the Tuple. Tuples and Values can be serialized and deserialized to and from ByteBuffers. This is mechanism which is used to save them to disk. Tuples are used as keys in SQL indexes and rows in SQL tables. Also included is a test file.
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>
LibSQL: Basic dynamic value classes for SQL Storage layer This patch adds the basic dynamic value classes used by the SQL Storage layer. The most elementary class is Value, which holds a typed Value which can be converted to standard C++ types. A Tuple is a collection of Values described by a TupleDescriptor, which specifies the names, types, and ordering of the elements in the Tuple. Tuples and Values can be serialized and deserialized to and from ByteBuffers. This is mechanism which is used to save them to disk. Tuples are used as keys in SQL indexes and rows in SQL tables. Also included is a test file.
2021-06-17 13:23:52 -04:00
*
* SPDX-License-Identifier: BSD-2-Clause
*/
#pragma once
LibSQL: Support 64-bit integer values and handle overflow errors Currently, integers are stored in LibSQL as 32-bit signed integers, even if the provided type is unsigned. This resulted in a series of unchecked unsigned-to-signed conversions, and prevented storing 64-bit values. Further, mathematical operations were performed without similar checks, and without checking for overflow. This changes SQL::Value to behave like SQLite for INTEGER types. In SQLite, the INTEGER type does not imply a size or signedness of the underlying type. Instead, SQLite determines on-the-fly what type is needed as values are created and updated. To do so, the SQL::Value variant can now hold an i64 or u64 integer. If a specific type is requested, invalid conversions are now explictly an error (e.g. converting a stored -1 to a u64 will fail). When binary mathematical operations are performed, we now try to coerce the RHS value to a type that works with the LHS value, failing the operation if that isn't possible. Any overflow or invalid operation (e.g. bitshifting a 64-bit value by more than 64 bytes) is an error.
2022-12-11 11:44:11 -05:00
#include <AK/Checked.h>
AK+Everywhere: Rename String to DeprecatedString We have a new, improved string type coming up in AK (OOM aware, no null state), and while it's going to use UTF-8, the name UTF8String is a mouthful - so let's free up the String name by renaming the existing class. Making the old one have an annoying name will hopefully also help with quick adoption :^)
2022-12-04 18:02:33 +00:00
#include <AK/DeprecatedString.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 <AK/Format.h>
#include <AK/Optional.h>
#include <AK/StringView.h>
LibSQL: Basic dynamic value classes for SQL Storage layer This patch adds the basic dynamic value classes used by the SQL Storage layer. The most elementary class is Value, which holds a typed Value which can be converted to standard C++ types. A Tuple is a collection of Values described by a TupleDescriptor, which specifies the names, types, and ordering of the elements in the Tuple. Tuples and Values can be serialized and deserialized to and from ByteBuffers. This is mechanism which is used to save them to disk. Tuples are used as keys in SQL indexes and rows in SQL tables. Also included is a test file.
2021-06-17 13:23:52 -04:00
#include <AK/Variant.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 <AK/Vector.h>
LibSQL: Add an IPC encoder/decoder for SQL::Value This will allow clients to send placeholder values for prepared statements over IPC.
2022-12-01 22:29:17 -05:00
#include <LibIPC/Forward.h>
LibSQL: Introduce Serializer as a mediator between Heap and client code Classes reading and writing to the data heap would communicate directly with the Heap object, and transfer ByteBuffers back and forth with it. This makes things like caching and locking hard. Therefore all data persistence activity will be funneled through a Serializer object which in turn submits it to the Heap. Introducing this unfortunately resulted in a huge amount of churn, in which a number of smaller refactorings got caught up as well.
2021-08-18 20:50:13 -04:00
#include <LibSQL/Forward.h>
LibSQL: Convert binary SQL operations to be fallible Now that expression evaluation can use TRY, we can allow binary operator methods to fail as well. This also fixes a few instances of converting a Value to a double when we meant to convert to an integer.
2022-02-11 10:23:20 -05:00
#include <LibSQL/Result.h>
LibSQL: Basic dynamic value classes for SQL Storage layer This patch adds the basic dynamic value classes used by the SQL Storage layer. The most elementary class is Value, which holds a typed Value which can be converted to standard C++ types. A Tuple is a collection of Values described by a TupleDescriptor, which specifies the names, types, and ordering of the elements in the Tuple. Tuples and Values can be serialized and deserialized to and from ByteBuffers. This is mechanism which is used to save them to disk. Tuples are used as keys in SQL indexes and rows in SQL tables. Also included is a test file.
2021-06-17 13:23:52 -04:00
#include <LibSQL/Type.h>
LibSQL: Support 64-bit integer values and handle overflow errors Currently, integers are stored in LibSQL as 32-bit signed integers, even if the provided type is unsigned. This resulted in a series of unchecked unsigned-to-signed conversions, and prevented storing 64-bit values. Further, mathematical operations were performed without similar checks, and without checking for overflow. This changes SQL::Value to behave like SQLite for INTEGER types. In SQLite, the INTEGER type does not imply a size or signedness of the underlying type. Instead, SQLite determines on-the-fly what type is needed as values are created and updated. To do so, the SQL::Value variant can now hold an i64 or u64 integer. If a specific type is requested, invalid conversions are now explictly an error (e.g. converting a stored -1 to a u64 will fail). When binary mathematical operations are performed, we now try to coerce the RHS value to a type that works with the LHS value, failing the operation if that isn't possible. Any overflow or invalid operation (e.g. bitshifting a 64-bit value by more than 64 bytes) is an error.
2022-12-11 11:44:11 -05:00
#include <math.h>
LibSQL: Basic dynamic value classes for SQL Storage layer This patch adds the basic dynamic value classes used by the SQL Storage layer. The most elementary class is Value, which holds a typed Value which can be converted to standard C++ types. A Tuple is a collection of Values described by a TupleDescriptor, which specifies the names, types, and ordering of the elements in the Tuple. Tuples and Values can be serialized and deserialized to and from ByteBuffers. This is mechanism which is used to save them to disk. Tuples are used as keys in SQL indexes and rows in SQL tables. Also included is a test file.
2021-06-17 13:23:52 -04:00
namespace SQL {
LibSQL: Support 64-bit integer values and handle overflow errors Currently, integers are stored in LibSQL as 32-bit signed integers, even if the provided type is unsigned. This resulted in a series of unchecked unsigned-to-signed conversions, and prevented storing 64-bit values. Further, mathematical operations were performed without similar checks, and without checking for overflow. This changes SQL::Value to behave like SQLite for INTEGER types. In SQLite, the INTEGER type does not imply a size or signedness of the underlying type. Instead, SQLite determines on-the-fly what type is needed as values are created and updated. To do so, the SQL::Value variant can now hold an i64 or u64 integer. If a specific type is requested, invalid conversions are now explictly an error (e.g. converting a stored -1 to a u64 will fail). When binary mathematical operations are performed, we now try to coerce the RHS value to a type that works with the LHS value, failing the operation if that isn't possible. Any overflow or invalid operation (e.g. bitshifting a 64-bit value by more than 64 bytes) is an error.
2022-12-11 11:44:11 -05:00
template<typename T>
concept Boolean = SameAs<RemoveCVReference<T>, bool>;
template<typename T>
concept Integer = (Integral<T> && !Boolean<T>);
LibSQL: Basic dynamic value classes for SQL Storage layer This patch adds the basic dynamic value classes used by the SQL Storage layer. The most elementary class is Value, which holds a typed Value which can be converted to standard C++ types. A Tuple is a collection of Values described by a TupleDescriptor, which specifies the names, types, and ordering of the elements in the Tuple. Tuples and Values can be serialized and deserialized to and from ByteBuffers. This is mechanism which is used to save them to disk. Tuples are used as keys in SQL indexes and rows in SQL tables. Also included is a test file.
2021-06-17 13:23:52 -04:00
/**
LibSQL: Introduce Serializer as a mediator between Heap and client code Classes reading and writing to the data heap would communicate directly with the Heap object, and transfer ByteBuffers back and forth with it. This makes things like caching and locking hard. Therefore all data persistence activity will be funneled through a Serializer object which in turn submits it to the Heap. Introducing this unfortunately resulted in a huge amount of churn, in which a number of smaller refactorings got caught up as well.
2021-08-18 20:50:13 -04:00
* A `Value` is an atomic piece of SQL data`. A `Value` has a basic type
LibSQL: Basic dynamic value classes for SQL Storage layer This patch adds the basic dynamic value classes used by the SQL Storage layer. The most elementary class is Value, which holds a typed Value which can be converted to standard C++ types. A Tuple is a collection of Values described by a TupleDescriptor, which specifies the names, types, and ordering of the elements in the Tuple. Tuples and Values can be serialized and deserialized to and from ByteBuffers. This is mechanism which is used to save them to disk. Tuples are used as keys in SQL indexes and rows in SQL tables. Also included is a test file.
2021-06-17 13:23:52 -04:00
* (Text/String, Integer, Float, etc). Richer types are implemented in higher
* level layers, but the resulting data is stored in these `Value` objects.
*/
class Value {
LibSQL: Support 64-bit integer values and handle overflow errors Currently, integers are stored in LibSQL as 32-bit signed integers, even if the provided type is unsigned. This resulted in a series of unchecked unsigned-to-signed conversions, and prevented storing 64-bit values. Further, mathematical operations were performed without similar checks, and without checking for overflow. This changes SQL::Value to behave like SQLite for INTEGER types. In SQLite, the INTEGER type does not imply a size or signedness of the underlying type. Instead, SQLite determines on-the-fly what type is needed as values are created and updated. To do so, the SQL::Value variant can now hold an i64 or u64 integer. If a specific type is requested, invalid conversions are now explictly an error (e.g. converting a stored -1 to a u64 will fail). When binary mathematical operations are performed, we now try to coerce the RHS value to a type that works with the LHS value, failing the operation if that isn't possible. Any overflow or invalid operation (e.g. bitshifting a 64-bit value by more than 64 bytes) is an error.
2022-12-11 11:44:11 -05:00
template<Integer T>
using IntegerType = Conditional<IsSigned<T>, i64, u64>;
LibSQL: Basic dynamic value classes for SQL Storage layer This patch adds the basic dynamic value classes used by the SQL Storage layer. The most elementary class is Value, which holds a typed Value which can be converted to standard C++ types. A Tuple is a collection of Values described by a TupleDescriptor, which specifies the names, types, and ordering of the elements in the Tuple. Tuples and Values can be serialized and deserialized to and from ByteBuffers. This is mechanism which is used to save them to disk. Tuples are used as keys in SQL indexes and rows in SQL tables. Also included is a test file.
2021-06-17 13:23:52 -04:00
public:
LibSQL: Redesign Value implementation and add new types The implemtation of the Value class was based on lambda member variables implementing type-dependent behaviour. This was done to ensure that Values can be used as stack-only objects; the simplest alternative, virtual methods, forces them onto the heap. The problem with the the lambda approach is that it bloats the Values (which are supposed to be lightweight objects) quite considerably, because every object contains more than a dozen function pointers. The solution to address both problems (we want Values to be able to live on the stack and be as lightweight as possible) chosen here is to encapsulate type-dependent behaviour and state in an implementation class, and let the Value be an AK::Variant of those implementation classes. All methods of Value are now basically straight delegates to the implementation object using the Variant::visit method. One issue complicating matters is the addition of two aggregate types, Tuple and Array, which each contain a Vector of Values. At this point Tuples and Arrays (and potential future aggregate types) can't contain these aggregate types. This is limiting and needs to be addressed. Another area that needs attention is the nomenclature of things; it's a bit of a tangle of 'ValueBlahBlah' and 'ImplBlahBlah'. It makes sense right now I think but admit we probably can do better. Other things included here: - Added the Boolean and Null types (and Tuple and Array, see above). - to_string now always succeeds and returns a String instead of an Optional. This had some impact on other sources. - Added a lot of tests. - Started moving the serialization mechanism more towards where I want it to be, i.e. a 'DataSerializer' object which just takes serialization and deserialization requests and knows for example how to store long strings out-of-line. One last remark: There is obviously a naming clash between the Tuple class and the Tuple Value type. This is intentional; I plan to make the Tuple class a subclass of Value (and hence Key and Row as well).
2021-07-17 07:02:28 -04:00
explicit Value(SQLType sql_type = SQLType::Null);
AK+Everywhere: Rename String to DeprecatedString We have a new, improved string type coming up in AK (OOM aware, no null state), and while it's going to use UTF-8, the name UTF8String is a mouthful - so let's free up the String name by renaming the existing class. Making the old one have an annoying name will hopefully also help with quick adoption :^)
2022-12-04 18:02:33 +00:00
explicit Value(DeprecatedString);
LibSQL: Redesign Value implementation and add new types The implemtation of the Value class was based on lambda member variables implementing type-dependent behaviour. This was done to ensure that Values can be used as stack-only objects; the simplest alternative, virtual methods, forces them onto the heap. The problem with the the lambda approach is that it bloats the Values (which are supposed to be lightweight objects) quite considerably, because every object contains more than a dozen function pointers. The solution to address both problems (we want Values to be able to live on the stack and be as lightweight as possible) chosen here is to encapsulate type-dependent behaviour and state in an implementation class, and let the Value be an AK::Variant of those implementation classes. All methods of Value are now basically straight delegates to the implementation object using the Variant::visit method. One issue complicating matters is the addition of two aggregate types, Tuple and Array, which each contain a Vector of Values. At this point Tuples and Arrays (and potential future aggregate types) can't contain these aggregate types. This is limiting and needs to be addressed. Another area that needs attention is the nomenclature of things; it's a bit of a tangle of 'ValueBlahBlah' and 'ImplBlahBlah'. It makes sense right now I think but admit we probably can do better. Other things included here: - Added the Boolean and Null types (and Tuple and Array, see above). - to_string now always succeeds and returns a String instead of an Optional. This had some impact on other sources. - Added a lot of tests. - Started moving the serialization mechanism more towards where I want it to be, i.e. a 'DataSerializer' object which just takes serialization and deserialization requests and knows for example how to store long strings out-of-line. One last remark: There is obviously a naming clash between the Tuple class and the Tuple Value type. This is intentional; I plan to make the Tuple class a subclass of Value (and hence Key and Row as well).
2021-07-17 07:02:28 -04:00
explicit Value(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
Value(Value const&);
Value(Value&&);
~Value();
LibSQL: Redesign Value implementation and add new types The implemtation of the Value class was based on lambda member variables implementing type-dependent behaviour. This was done to ensure that Values can be used as stack-only objects; the simplest alternative, virtual methods, forces them onto the heap. The problem with the the lambda approach is that it bloats the Values (which are supposed to be lightweight objects) quite considerably, because every object contains more than a dozen function pointers. The solution to address both problems (we want Values to be able to live on the stack and be as lightweight as possible) chosen here is to encapsulate type-dependent behaviour and state in an implementation class, and let the Value be an AK::Variant of those implementation classes. All methods of Value are now basically straight delegates to the implementation object using the Variant::visit method. One issue complicating matters is the addition of two aggregate types, Tuple and Array, which each contain a Vector of Values. At this point Tuples and Arrays (and potential future aggregate types) can't contain these aggregate types. This is limiting and needs to be addressed. Another area that needs attention is the nomenclature of things; it's a bit of a tangle of 'ValueBlahBlah' and 'ImplBlahBlah'. It makes sense right now I think but admit we probably can do better. Other things included here: - Added the Boolean and Null types (and Tuple and Array, see above). - to_string now always succeeds and returns a String instead of an Optional. This had some impact on other sources. - Added a lot of tests. - Started moving the serialization mechanism more towards where I want it to be, i.e. a 'DataSerializer' object which just takes serialization and deserialization requests and knows for example how to store long strings out-of-line. One last remark: There is obviously a naming clash between the Tuple class and the Tuple Value type. This is intentional; I plan to make the Tuple class a subclass of Value (and hence Key and Row as well).
2021-07-17 07:02:28 -04:00
LibSQL: Support 64-bit integer values and handle overflow errors Currently, integers are stored in LibSQL as 32-bit signed integers, even if the provided type is unsigned. This resulted in a series of unchecked unsigned-to-signed conversions, and prevented storing 64-bit values. Further, mathematical operations were performed without similar checks, and without checking for overflow. This changes SQL::Value to behave like SQLite for INTEGER types. In SQLite, the INTEGER type does not imply a size or signedness of the underlying type. Instead, SQLite determines on-the-fly what type is needed as values are created and updated. To do so, the SQL::Value variant can now hold an i64 or u64 integer. If a specific type is requested, invalid conversions are now explictly an error (e.g. converting a stored -1 to a u64 will fail). When binary mathematical operations are performed, we now try to coerce the RHS value to a type that works with the LHS value, failing the operation if that isn't possible. Any overflow or invalid operation (e.g. bitshifting a 64-bit value by more than 64 bytes) is an error.
2022-12-11 11:44:11 -05:00
explicit Value(Integer auto value)
: m_type(SQLType::Integer)
, m_value(static_cast<IntegerType<decltype(value)>>(value))
{
}
LibSQL: Redesign Value implementation and add new types The implemtation of the Value class was based on lambda member variables implementing type-dependent behaviour. This was done to ensure that Values can be used as stack-only objects; the simplest alternative, virtual methods, forces them onto the heap. The problem with the the lambda approach is that it bloats the Values (which are supposed to be lightweight objects) quite considerably, because every object contains more than a dozen function pointers. The solution to address both problems (we want Values to be able to live on the stack and be as lightweight as possible) chosen here is to encapsulate type-dependent behaviour and state in an implementation class, and let the Value be an AK::Variant of those implementation classes. All methods of Value are now basically straight delegates to the implementation object using the Variant::visit method. One issue complicating matters is the addition of two aggregate types, Tuple and Array, which each contain a Vector of Values. At this point Tuples and Arrays (and potential future aggregate types) can't contain these aggregate types. This is limiting and needs to be addressed. Another area that needs attention is the nomenclature of things; it's a bit of a tangle of 'ValueBlahBlah' and 'ImplBlahBlah'. It makes sense right now I think but admit we probably can do better. Other things included here: - Added the Boolean and Null types (and Tuple and Array, see above). - to_string now always succeeds and returns a String instead of an Optional. This had some impact on other sources. - Added a lot of tests. - Started moving the serialization mechanism more towards where I want it to be, i.e. a 'DataSerializer' object which just takes serialization and deserialization requests and knows for example how to store long strings out-of-line. One last remark: There is obviously a naming clash between the Tuple class and the Tuple Value type. This is intentional; I plan to make the Tuple class a subclass of Value (and hence Key and Row as well).
2021-07-17 07:02:28 -04:00
LibSQL: Support 64-bit integer values and handle overflow errors Currently, integers are stored in LibSQL as 32-bit signed integers, even if the provided type is unsigned. This resulted in a series of unchecked unsigned-to-signed conversions, and prevented storing 64-bit values. Further, mathematical operations were performed without similar checks, and without checking for overflow. This changes SQL::Value to behave like SQLite for INTEGER types. In SQLite, the INTEGER type does not imply a size or signedness of the underlying type. Instead, SQLite determines on-the-fly what type is needed as values are created and updated. To do so, the SQL::Value variant can now hold an i64 or u64 integer. If a specific type is requested, invalid conversions are now explictly an error (e.g. converting a stored -1 to a u64 will fail). When binary mathematical operations are performed, we now try to coerce the RHS value to a type that works with the LHS value, failing the operation if that isn't possible. Any overflow or invalid operation (e.g. bitshifting a 64-bit value by more than 64 bytes) is an error.
2022-12-11 11:44:11 -05:00
explicit Value(Boolean auto 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::Boolean)
, m_value(value)
{
}
LibSQL: Redesign Value implementation and add new types The implemtation of the Value class was based on lambda member variables implementing type-dependent behaviour. This was done to ensure that Values can be used as stack-only objects; the simplest alternative, virtual methods, forces them onto the heap. The problem with the the lambda approach is that it bloats the Values (which are supposed to be lightweight objects) quite considerably, because every object contains more than a dozen function pointers. The solution to address both problems (we want Values to be able to live on the stack and be as lightweight as possible) chosen here is to encapsulate type-dependent behaviour and state in an implementation class, and let the Value be an AK::Variant of those implementation classes. All methods of Value are now basically straight delegates to the implementation object using the Variant::visit method. One issue complicating matters is the addition of two aggregate types, Tuple and Array, which each contain a Vector of Values. At this point Tuples and Arrays (and potential future aggregate types) can't contain these aggregate types. This is limiting and needs to be addressed. Another area that needs attention is the nomenclature of things; it's a bit of a tangle of 'ValueBlahBlah' and 'ImplBlahBlah'. It makes sense right now I think but admit we probably can do better. Other things included here: - Added the Boolean and Null types (and Tuple and Array, see above). - to_string now always succeeds and returns a String instead of an Optional. This had some impact on other sources. - Added a lot of tests. - Started moving the serialization mechanism more towards where I want it to be, i.e. a 'DataSerializer' object which just takes serialization and deserialization requests and knows for example how to store long strings out-of-line. One last remark: There is obviously a naming clash between the Tuple class and the Tuple Value type. This is intentional; I plan to make the Tuple class a subclass of Value (and hence Key and Row as well).
2021-07-17 07:02:28 -04:00
LibSQL: Support 64-bit integer values and handle overflow errors Currently, integers are stored in LibSQL as 32-bit signed integers, even if the provided type is unsigned. This resulted in a series of unchecked unsigned-to-signed conversions, and prevented storing 64-bit values. Further, mathematical operations were performed without similar checks, and without checking for overflow. This changes SQL::Value to behave like SQLite for INTEGER types. In SQLite, the INTEGER type does not imply a size or signedness of the underlying type. Instead, SQLite determines on-the-fly what type is needed as values are created and updated. To do so, the SQL::Value variant can now hold an i64 or u64 integer. If a specific type is requested, invalid conversions are now explictly an error (e.g. converting a stored -1 to a u64 will fail). When binary mathematical operations are performed, we now try to coerce the RHS value to a type that works with the LHS value, failing the operation if that isn't possible. Any overflow or invalid operation (e.g. bitshifting a 64-bit value by more than 64 bytes) is an error.
2022-12-11 11:44:11 -05:00
static ResultOr<Value> create_tuple(NonnullRefPtr<TupleDescriptor>);
static ResultOr<Value> create_tuple(Vector<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
[[nodiscard]] SQLType type() const;
[[nodiscard]] StringView type_name() const;
LibSQL: Partially implement the UPDATE command This implements enough to update rows filtered by a WHERE clause.
2022-12-05 07:55:21 -05:00
[[nodiscard]] bool is_type_compatible_with(SQLType) 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
[[nodiscard]] bool is_null() const;
LibSQL: Support 64-bit integer values and handle overflow errors Currently, integers are stored in LibSQL as 32-bit signed integers, even if the provided type is unsigned. This resulted in a series of unchecked unsigned-to-signed conversions, and prevented storing 64-bit values. Further, mathematical operations were performed without similar checks, and without checking for overflow. This changes SQL::Value to behave like SQLite for INTEGER types. In SQLite, the INTEGER type does not imply a size or signedness of the underlying type. Instead, SQLite determines on-the-fly what type is needed as values are created and updated. To do so, the SQL::Value variant can now hold an i64 or u64 integer. If a specific type is requested, invalid conversions are now explictly an error (e.g. converting a stored -1 to a u64 will fail). When binary mathematical operations are performed, we now try to coerce the RHS value to a type that works with the LHS value, failing the operation if that isn't possible. Any overflow or invalid operation (e.g. bitshifting a 64-bit value by more than 64 bytes) is an error.
2022-12-11 11:44:11 -05:00
[[nodiscard]] bool is_int() const;
[[nodiscard]] auto const& value() const
{
VERIFY(m_value.has_value());
return *m_value;
}
LibSQL: Redesign Value implementation and add new types The implemtation of the Value class was based on lambda member variables implementing type-dependent behaviour. This was done to ensure that Values can be used as stack-only objects; the simplest alternative, virtual methods, forces them onto the heap. The problem with the the lambda approach is that it bloats the Values (which are supposed to be lightweight objects) quite considerably, because every object contains more than a dozen function pointers. The solution to address both problems (we want Values to be able to live on the stack and be as lightweight as possible) chosen here is to encapsulate type-dependent behaviour and state in an implementation class, and let the Value be an AK::Variant of those implementation classes. All methods of Value are now basically straight delegates to the implementation object using the Variant::visit method. One issue complicating matters is the addition of two aggregate types, Tuple and Array, which each contain a Vector of Values. At this point Tuples and Arrays (and potential future aggregate types) can't contain these aggregate types. This is limiting and needs to be addressed. Another area that needs attention is the nomenclature of things; it's a bit of a tangle of 'ValueBlahBlah' and 'ImplBlahBlah'. It makes sense right now I think but admit we probably can do better. Other things included here: - Added the Boolean and Null types (and Tuple and Array, see above). - to_string now always succeeds and returns a String instead of an Optional. This had some impact on other sources. - Added a lot of tests. - Started moving the serialization mechanism more towards where I want it to be, i.e. a 'DataSerializer' object which just takes serialization and deserialization requests and knows for example how to store long strings out-of-line. One last remark: There is obviously a naming clash between the Tuple class and the Tuple Value type. This is intentional; I plan to make the Tuple class a subclass of Value (and hence Key and Row as well).
2021-07-17 07:02:28 -04:00
Everywhere: Rename to_{string => deprecated_string}() where applicable This will make it easier to support both string types at the same time while we convert code, and tracking down remaining uses. One big exception is Value::to_string() in LibJS, where the name is dictated by the ToString AO.
2022-12-06 01:12:49 +00:00
[[nodiscard]] DeprecatedString to_deprecated_string() const;
LibSQL: Redesign Value implementation and add new types The implemtation of the Value class was based on lambda member variables implementing type-dependent behaviour. This was done to ensure that Values can be used as stack-only objects; the simplest alternative, virtual methods, forces them onto the heap. The problem with the the lambda approach is that it bloats the Values (which are supposed to be lightweight objects) quite considerably, because every object contains more than a dozen function pointers. The solution to address both problems (we want Values to be able to live on the stack and be as lightweight as possible) chosen here is to encapsulate type-dependent behaviour and state in an implementation class, and let the Value be an AK::Variant of those implementation classes. All methods of Value are now basically straight delegates to the implementation object using the Variant::visit method. One issue complicating matters is the addition of two aggregate types, Tuple and Array, which each contain a Vector of Values. At this point Tuples and Arrays (and potential future aggregate types) can't contain these aggregate types. This is limiting and needs to be addressed. Another area that needs attention is the nomenclature of things; it's a bit of a tangle of 'ValueBlahBlah' and 'ImplBlahBlah'. It makes sense right now I think but admit we probably can do better. Other things included here: - Added the Boolean and Null types (and Tuple and Array, see above). - to_string now always succeeds and returns a String instead of an Optional. This had some impact on other sources. - Added a lot of tests. - Started moving the serialization mechanism more towards where I want it to be, i.e. a 'DataSerializer' object which just takes serialization and deserialization requests and knows for example how to store long strings out-of-line. One last remark: There is obviously a naming clash between the Tuple class and the Tuple Value type. This is intentional; I plan to make the Tuple class a subclass of Value (and hence Key and Row as well).
2021-07-17 07:02:28 -04:00
[[nodiscard]] Optional<double> to_double() const;
[[nodiscard]] Optional<bool> to_bool() const;
[[nodiscard]] Optional<Vector<Value>> to_vector() const;
LibSQL: Support 64-bit integer values and handle overflow errors Currently, integers are stored in LibSQL as 32-bit signed integers, even if the provided type is unsigned. This resulted in a series of unchecked unsigned-to-signed conversions, and prevented storing 64-bit values. Further, mathematical operations were performed without similar checks, and without checking for overflow. This changes SQL::Value to behave like SQLite for INTEGER types. In SQLite, the INTEGER type does not imply a size or signedness of the underlying type. Instead, SQLite determines on-the-fly what type is needed as values are created and updated. To do so, the SQL::Value variant can now hold an i64 or u64 integer. If a specific type is requested, invalid conversions are now explictly an error (e.g. converting a stored -1 to a u64 will fail). When binary mathematical operations are performed, we now try to coerce the RHS value to a type that works with the LHS value, failing the operation if that isn't possible. Any overflow or invalid operation (e.g. bitshifting a 64-bit value by more than 64 bytes) is an error.
2022-12-11 11:44:11 -05:00
template<Integer T>
[[nodiscard]] Optional<T> to_int() const
{
if (is_null())
return {};
return m_value->visit(
[](DeprecatedString const& value) -> Optional<T> {
if constexpr (IsSigned<T>)
return value.to_int<T>();
else
return value.to_uint<T>();
},
[](Integer auto value) -> Optional<T> {
if (!AK::is_within_range<T>(value))
return {};
return static_cast<T>(value);
},
[](double value) -> Optional<T> {
if (!AK::is_within_range<T>(value))
return {};
return static_cast<T>(round(value));
},
[](bool value) -> Optional<T> { return static_cast<T>(value); },
[](TupleValue const&) -> Optional<T> { 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
Value& operator=(Value);
AK+Everywhere: Rename String to DeprecatedString We have a new, improved string type coming up in AK (OOM aware, no null state), and while it's going to use UTF-8, the name UTF8String is a mouthful - so let's free up the String name by renaming the existing class. Making the old one have an annoying name will hopefully also help with quick adoption :^)
2022-12-04 18:02:33 +00:00
Value& operator=(DeprecatedString);
LibSQL: Redesign Value implementation and add new types The implemtation of the Value class was based on lambda member variables implementing type-dependent behaviour. This was done to ensure that Values can be used as stack-only objects; the simplest alternative, virtual methods, forces them onto the heap. The problem with the the lambda approach is that it bloats the Values (which are supposed to be lightweight objects) quite considerably, because every object contains more than a dozen function pointers. The solution to address both problems (we want Values to be able to live on the stack and be as lightweight as possible) chosen here is to encapsulate type-dependent behaviour and state in an implementation class, and let the Value be an AK::Variant of those implementation classes. All methods of Value are now basically straight delegates to the implementation object using the Variant::visit method. One issue complicating matters is the addition of two aggregate types, Tuple and Array, which each contain a Vector of Values. At this point Tuples and Arrays (and potential future aggregate types) can't contain these aggregate types. This is limiting and needs to be addressed. Another area that needs attention is the nomenclature of things; it's a bit of a tangle of 'ValueBlahBlah' and 'ImplBlahBlah'. It makes sense right now I think but admit we probably can do better. Other things included here: - Added the Boolean and Null types (and Tuple and Array, see above). - to_string now always succeeds and returns a String instead of an Optional. This had some impact on other sources. - Added a lot of tests. - Started moving the serialization mechanism more towards where I want it to be, i.e. a 'DataSerializer' object which just takes serialization and deserialization requests and knows for example how to store long strings out-of-line. One last remark: There is obviously a naming clash between the Tuple class and the Tuple Value type. This is intentional; I plan to make the Tuple class a subclass of Value (and hence Key and Row as well).
2021-07-17 07:02:28 -04:00
Value& operator=(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
LibSQL: Support 64-bit integer values and handle overflow errors Currently, integers are stored in LibSQL as 32-bit signed integers, even if the provided type is unsigned. This resulted in a series of unchecked unsigned-to-signed conversions, and prevented storing 64-bit values. Further, mathematical operations were performed without similar checks, and without checking for overflow. This changes SQL::Value to behave like SQLite for INTEGER types. In SQLite, the INTEGER type does not imply a size or signedness of the underlying type. Instead, SQLite determines on-the-fly what type is needed as values are created and updated. To do so, the SQL::Value variant can now hold an i64 or u64 integer. If a specific type is requested, invalid conversions are now explictly an error (e.g. converting a stored -1 to a u64 will fail). When binary mathematical operations are performed, we now try to coerce the RHS value to a type that works with the LHS value, failing the operation if that isn't possible. Any overflow or invalid operation (e.g. bitshifting a 64-bit value by more than 64 bytes) is an error.
2022-12-11 11:44:11 -05:00
Value& operator=(Integer auto value)
{
m_type = SQLType::Integer;
m_value = static_cast<IntegerType<decltype(value)>>(value);
return *this;
}
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> assign_tuple(NonnullRefPtr<TupleDescriptor>);
ResultOr<void> assign_tuple(Vector<Value>);
LibSQL: Support 64-bit integer values and handle overflow errors Currently, integers are stored in LibSQL as 32-bit signed integers, even if the provided type is unsigned. This resulted in a series of unchecked unsigned-to-signed conversions, and prevented storing 64-bit values. Further, mathematical operations were performed without similar checks, and without checking for overflow. This changes SQL::Value to behave like SQLite for INTEGER types. In SQLite, the INTEGER type does not imply a size or signedness of the underlying type. Instead, SQLite determines on-the-fly what type is needed as values are created and updated. To do so, the SQL::Value variant can now hold an i64 or u64 integer. If a specific type is requested, invalid conversions are now explictly an error (e.g. converting a stored -1 to a u64 will fail). When binary mathematical operations are performed, we now try to coerce the RHS value to a type that works with the LHS value, failing the operation if that isn't possible. Any overflow or invalid operation (e.g. bitshifting a 64-bit value by more than 64 bytes) is an error.
2022-12-11 11:44:11 -05:00
Value& operator=(Boolean auto 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::Boolean;
m_value = value;
return *this;
}
LibSQL: Redesign Value implementation and add new types The implemtation of the Value class was based on lambda member variables implementing type-dependent behaviour. This was done to ensure that Values can be used as stack-only objects; the simplest alternative, virtual methods, forces them onto the heap. The problem with the the lambda approach is that it bloats the Values (which are supposed to be lightweight objects) quite considerably, because every object contains more than a dozen function pointers. The solution to address both problems (we want Values to be able to live on the stack and be as lightweight as possible) chosen here is to encapsulate type-dependent behaviour and state in an implementation class, and let the Value be an AK::Variant of those implementation classes. All methods of Value are now basically straight delegates to the implementation object using the Variant::visit method. One issue complicating matters is the addition of two aggregate types, Tuple and Array, which each contain a Vector of Values. At this point Tuples and Arrays (and potential future aggregate types) can't contain these aggregate types. This is limiting and needs to be addressed. Another area that needs attention is the nomenclature of things; it's a bit of a tangle of 'ValueBlahBlah' and 'ImplBlahBlah'. It makes sense right now I think but admit we probably can do better. Other things included here: - Added the Boolean and Null types (and Tuple and Array, see above). - to_string now always succeeds and returns a String instead of an Optional. This had some impact on other sources. - Added a lot of tests. - Started moving the serialization mechanism more towards where I want it to be, i.e. a 'DataSerializer' object which just takes serialization and deserialization requests and knows for example how to store long strings out-of-line. One last remark: There is obviously a naming clash between the Tuple class and the Tuple Value type. This is intentional; I plan to make the Tuple class a subclass of Value (and hence Key and Row as well).
2021-07-17 07:02:28 -04:00
[[nodiscard]] size_t length() const;
[[nodiscard]] u32 hash() const;
LibSQL: Introduce Serializer as a mediator between Heap and client code Classes reading and writing to the data heap would communicate directly with the Heap object, and transfer ByteBuffers back and forth with it. This makes things like caching and locking hard. Therefore all data persistence activity will be funneled through a Serializer object which in turn submits it to the Heap. Introducing this unfortunately resulted in a huge amount of churn, in which a number of smaller refactorings got caught up as well.
2021-08-18 20:50:13 -04:00
void serialize(Serializer&) const;
void deserialize(Serializer&);
LibSQL: Basic dynamic value classes for SQL Storage layer This patch adds the basic dynamic value classes used by the SQL Storage layer. The most elementary class is Value, which holds a typed Value which can be converted to standard C++ types. A Tuple is a collection of Values described by a TupleDescriptor, which specifies the names, types, and ordering of the elements in the Tuple. Tuples and Values can be serialized and deserialized to and from ByteBuffers. This is mechanism which is used to save them to disk. Tuples are used as keys in SQL indexes and rows in SQL tables. Also included is a test file.
2021-06-17 13:23:52 -04:00
LibSQL: Redesign Value implementation and add new types The implemtation of the Value class was based on lambda member variables implementing type-dependent behaviour. This was done to ensure that Values can be used as stack-only objects; the simplest alternative, virtual methods, forces them onto the heap. The problem with the the lambda approach is that it bloats the Values (which are supposed to be lightweight objects) quite considerably, because every object contains more than a dozen function pointers. The solution to address both problems (we want Values to be able to live on the stack and be as lightweight as possible) chosen here is to encapsulate type-dependent behaviour and state in an implementation class, and let the Value be an AK::Variant of those implementation classes. All methods of Value are now basically straight delegates to the implementation object using the Variant::visit method. One issue complicating matters is the addition of two aggregate types, Tuple and Array, which each contain a Vector of Values. At this point Tuples and Arrays (and potential future aggregate types) can't contain these aggregate types. This is limiting and needs to be addressed. Another area that needs attention is the nomenclature of things; it's a bit of a tangle of 'ValueBlahBlah' and 'ImplBlahBlah'. It makes sense right now I think but admit we probably can do better. Other things included here: - Added the Boolean and Null types (and Tuple and Array, see above). - to_string now always succeeds and returns a String instead of an Optional. This had some impact on other sources. - Added a lot of tests. - Started moving the serialization mechanism more towards where I want it to be, i.e. a 'DataSerializer' object which just takes serialization and deserialization requests and knows for example how to store long strings out-of-line. One last remark: There is obviously a naming clash between the Tuple class and the Tuple Value type. This is intentional; I plan to make the Tuple class a subclass of Value (and hence Key and Row as well).
2021-07-17 07:02:28 -04:00
[[nodiscard]] int compare(Value const&) const;
bool operator==(Value const&) 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
bool operator==(StringView) const;
LibSQL: Redesign Value implementation and add new types The implemtation of the Value class was based on lambda member variables implementing type-dependent behaviour. This was done to ensure that Values can be used as stack-only objects; the simplest alternative, virtual methods, forces them onto the heap. The problem with the the lambda approach is that it bloats the Values (which are supposed to be lightweight objects) quite considerably, because every object contains more than a dozen function pointers. The solution to address both problems (we want Values to be able to live on the stack and be as lightweight as possible) chosen here is to encapsulate type-dependent behaviour and state in an implementation class, and let the Value be an AK::Variant of those implementation classes. All methods of Value are now basically straight delegates to the implementation object using the Variant::visit method. One issue complicating matters is the addition of two aggregate types, Tuple and Array, which each contain a Vector of Values. At this point Tuples and Arrays (and potential future aggregate types) can't contain these aggregate types. This is limiting and needs to be addressed. Another area that needs attention is the nomenclature of things; it's a bit of a tangle of 'ValueBlahBlah' and 'ImplBlahBlah'. It makes sense right now I think but admit we probably can do better. Other things included here: - Added the Boolean and Null types (and Tuple and Array, see above). - to_string now always succeeds and returns a String instead of an Optional. This had some impact on other sources. - Added a lot of tests. - Started moving the serialization mechanism more towards where I want it to be, i.e. a 'DataSerializer' object which just takes serialization and deserialization requests and knows for example how to store long strings out-of-line. One last remark: There is obviously a naming clash between the Tuple class and the Tuple Value type. This is intentional; I plan to make the Tuple class a subclass of Value (and hence Key and Row as well).
2021-07-17 07:02:28 -04:00
bool operator==(double) const;
LibSQL: Support 64-bit integer values and handle overflow errors Currently, integers are stored in LibSQL as 32-bit signed integers, even if the provided type is unsigned. This resulted in a series of unchecked unsigned-to-signed conversions, and prevented storing 64-bit values. Further, mathematical operations were performed without similar checks, and without checking for overflow. This changes SQL::Value to behave like SQLite for INTEGER types. In SQLite, the INTEGER type does not imply a size or signedness of the underlying type. Instead, SQLite determines on-the-fly what type is needed as values are created and updated. To do so, the SQL::Value variant can now hold an i64 or u64 integer. If a specific type is requested, invalid conversions are now explictly an error (e.g. converting a stored -1 to a u64 will fail). When binary mathematical operations are performed, we now try to coerce the RHS value to a type that works with the LHS value, failing the operation if that isn't possible. Any overflow or invalid operation (e.g. bitshifting a 64-bit value by more than 64 bytes) is an error.
2022-12-11 11:44:11 -05:00
template<Integer T>
bool operator==(T value)
{
return to_int<T>() == value;
}
LibSQL: Redesign Value implementation and add new types The implemtation of the Value class was based on lambda member variables implementing type-dependent behaviour. This was done to ensure that Values can be used as stack-only objects; the simplest alternative, virtual methods, forces them onto the heap. The problem with the the lambda approach is that it bloats the Values (which are supposed to be lightweight objects) quite considerably, because every object contains more than a dozen function pointers. The solution to address both problems (we want Values to be able to live on the stack and be as lightweight as possible) chosen here is to encapsulate type-dependent behaviour and state in an implementation class, and let the Value be an AK::Variant of those implementation classes. All methods of Value are now basically straight delegates to the implementation object using the Variant::visit method. One issue complicating matters is the addition of two aggregate types, Tuple and Array, which each contain a Vector of Values. At this point Tuples and Arrays (and potential future aggregate types) can't contain these aggregate types. This is limiting and needs to be addressed. Another area that needs attention is the nomenclature of things; it's a bit of a tangle of 'ValueBlahBlah' and 'ImplBlahBlah'. It makes sense right now I think but admit we probably can do better. Other things included here: - Added the Boolean and Null types (and Tuple and Array, see above). - to_string now always succeeds and returns a String instead of an Optional. This had some impact on other sources. - Added a lot of tests. - Started moving the serialization mechanism more towards where I want it to be, i.e. a 'DataSerializer' object which just takes serialization and deserialization requests and knows for example how to store long strings out-of-line. One last remark: There is obviously a naming clash between the Tuple class and the Tuple Value type. This is intentional; I plan to make the Tuple class a subclass of Value (and hence Key and Row as well).
2021-07-17 07:02:28 -04:00
bool operator!=(Value const&) const;
bool operator<(Value const&) const;
bool operator<=(Value const&) const;
bool operator>(Value const&) const;
bool operator>=(Value const&) const;
LibSQL: Convert binary SQL operations to be fallible Now that expression evaluation can use TRY, we can allow binary operator methods to fail as well. This also fixes a few instances of converting a Value to a double when we meant to convert to an integer.
2022-02-11 10:23:20 -05:00
ResultOr<Value> add(Value const&) const;
ResultOr<Value> subtract(Value const&) const;
ResultOr<Value> multiply(Value const&) const;
ResultOr<Value> divide(Value const&) const;
ResultOr<Value> modulo(Value const&) const;
LibSQL: Support 64-bit integer values and handle overflow errors Currently, integers are stored in LibSQL as 32-bit signed integers, even if the provided type is unsigned. This resulted in a series of unchecked unsigned-to-signed conversions, and prevented storing 64-bit values. Further, mathematical operations were performed without similar checks, and without checking for overflow. This changes SQL::Value to behave like SQLite for INTEGER types. In SQLite, the INTEGER type does not imply a size or signedness of the underlying type. Instead, SQLite determines on-the-fly what type is needed as values are created and updated. To do so, the SQL::Value variant can now hold an i64 or u64 integer. If a specific type is requested, invalid conversions are now explictly an error (e.g. converting a stored -1 to a u64 will fail). When binary mathematical operations are performed, we now try to coerce the RHS value to a type that works with the LHS value, failing the operation if that isn't possible. Any overflow or invalid operation (e.g. bitshifting a 64-bit value by more than 64 bytes) is an error.
2022-12-11 11:44:11 -05:00
ResultOr<Value> negate() const;
LibSQL: Convert binary SQL operations to be fallible Now that expression evaluation can use TRY, we can allow binary operator methods to fail as well. This also fixes a few instances of converting a Value to a double when we meant to convert to an integer.
2022-02-11 10:23:20 -05:00
ResultOr<Value> shift_left(Value const&) const;
ResultOr<Value> shift_right(Value const&) const;
ResultOr<Value> bitwise_or(Value const&) const;
ResultOr<Value> bitwise_and(Value const&) const;
LibSQL: Support 64-bit integer values and handle overflow errors Currently, integers are stored in LibSQL as 32-bit signed integers, even if the provided type is unsigned. This resulted in a series of unchecked unsigned-to-signed conversions, and prevented storing 64-bit values. Further, mathematical operations were performed without similar checks, and without checking for overflow. This changes SQL::Value to behave like SQLite for INTEGER types. In SQLite, the INTEGER type does not imply a size or signedness of the underlying type. Instead, SQLite determines on-the-fly what type is needed as values are created and updated. To do so, the SQL::Value variant can now hold an i64 or u64 integer. If a specific type is requested, invalid conversions are now explictly an error (e.g. converting a stored -1 to a u64 will fail). When binary mathematical operations are performed, we now try to coerce the RHS value to a type that works with the LHS value, failing the operation if that isn't possible. Any overflow or invalid operation (e.g. bitshifting a 64-bit value by more than 64 bytes) is an error.
2022-12-11 11:44:11 -05:00
ResultOr<Value> bitwise_not() const;
LibSQL: Implement binary operators for Value objects The behaviour of the various operators is supposed to mimic that of the same operators in PostgreSQL; the '+' operator for example will successfully add '98' (string) and 2 (integer), but not 'foo' and 2. Also removed some redundant const& parameter declarations for intrinsic types (ints and doubles etc). Passing those by const& doesn't make a lot of sense.
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
[[nodiscard]] TupleElementDescriptor descriptor() const;
LibSQL: Basic dynamic value classes for SQL Storage layer This patch adds the basic dynamic value classes used by the SQL Storage layer. The most elementary class is Value, which holds a typed Value which can be converted to standard C++ types. A Tuple is a collection of Values described by a TupleDescriptor, which specifies the names, types, and ordering of the elements in the Tuple. Tuples and Values can be serialized and deserialized to and from ByteBuffers. This is mechanism which is used to save them to disk. Tuples are used as keys in SQL indexes and rows in SQL tables. Also included is a test file.
2021-06-17 13:23:52 -04:00
private:
LibSQL: Introduce Serializer as a mediator between Heap and client code Classes reading and writing to the data heap would communicate directly with the Heap object, and transfer ByteBuffers back and forth with it. This makes things like caching and locking hard. Therefore all data persistence activity will be funneled through a Serializer object which in turn submits it to the Heap. Introducing this unfortunately resulted in a huge amount of churn, in which a number of smaller refactorings got caught up as well.
2021-08-18 20:50:13 -04:00
friend Serializer;
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
struct TupleValue {
NonnullRefPtr<TupleDescriptor> descriptor;
Vector<Value> values;
};
LibSQL: Support 64-bit integer values and handle overflow errors Currently, integers are stored in LibSQL as 32-bit signed integers, even if the provided type is unsigned. This resulted in a series of unchecked unsigned-to-signed conversions, and prevented storing 64-bit values. Further, mathematical operations were performed without similar checks, and without checking for overflow. This changes SQL::Value to behave like SQLite for INTEGER types. In SQLite, the INTEGER type does not imply a size or signedness of the underlying type. Instead, SQLite determines on-the-fly what type is needed as values are created and updated. To do so, the SQL::Value variant can now hold an i64 or u64 integer. If a specific type is requested, invalid conversions are now explictly an error (e.g. converting a stored -1 to a u64 will fail). When binary mathematical operations are performed, we now try to coerce the RHS value to a type that works with the LHS value, failing the operation if that isn't possible. Any overflow or invalid operation (e.g. bitshifting a 64-bit value by more than 64 bytes) is an error.
2022-12-11 11:44:11 -05:00
using ValueType = Variant<DeprecatedString, i64, u64, double, bool, TupleValue>;
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 ResultOr<NonnullRefPtr<TupleDescriptor>> infer_tuple_descriptor(Vector<Value> const& values);
Value(NonnullRefPtr<TupleDescriptor> descriptor, Vector<Value> values);
SQLType m_type { SQLType::Null };
Optional<ValueType> m_value;
LibSQL: Basic dynamic value classes for SQL Storage layer This patch adds the basic dynamic value classes used by the SQL Storage layer. The most elementary class is Value, which holds a typed Value which can be converted to standard C++ types. A Tuple is a collection of Values described by a TupleDescriptor, which specifies the names, types, and ordering of the elements in the Tuple. Tuples and Values can be serialized and deserialized to and from ByteBuffers. This is mechanism which is used to save them to disk. Tuples are used as keys in SQL indexes and rows in SQL tables. Also included is a test file.
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
template<>
struct AK::Formatter<SQL::Value> : Formatter<StringView> {
ErrorOr<void> format(FormatBuilder& builder, SQL::Value const& value)
{
Everywhere: Rename to_{string => deprecated_string}() where applicable This will make it easier to support both string types at the same time while we convert code, and tracking down remaining uses. One big exception is Value::to_string() in LibJS, where the name is dictated by the ToString AO.
2022-12-06 01:12:49 +00:00
return Formatter<StringView>::format(builder, value.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
}
};
LibSQL: Add an IPC encoder/decoder for SQL::Value This will allow clients to send placeholder values for prepared statements over IPC.
2022-12-01 22:29:17 -05:00
namespace IPC {
template<>
LibIPC+Everywhere: Change IPC::encode's return type to ErrorOr In doing so, this removes all uses of the Encoder's stream operator, except for where it is currently still used in the generated IPC code. So the stream operator currently discards any errors, which is the existing behavior. A subsequent commit will propagate the errors.
2023-01-01 23:37:35 -05:00
ErrorOr<void> encode(Encoder&, SQL::Value const&);
LibSQL: Add an IPC encoder/decoder for SQL::Value This will allow clients to send placeholder values for prepared statements over IPC.
2022-12-01 22:29:17 -05:00
template<>
LibIPC+Everywhere: Change IPC decoders to construct values in-place Currently, the generated IPC decoders will default-construct the type to be decoded, then pass that value by reference to the concrete decoder. This, of course, requires that the type is default-constructible. This was an issue for decoding Variants, which had to require the first type in the Variant list is Empty, to ensure it is default constructible. Further, this made it possible for values to become uninitialized in user-defined decoders. This patch makes the decoder interface such that the concrete decoders themselves contruct the decoded type upon return from the decoder. To do so, the default decoders in IPC::Decoder had to be moved to the IPC namespace scope, as these decoders are now specializations instead of overloaded methods (C++ requires specializations to be in a namespace scope).
2022-12-22 20:40:33 -05:00
ErrorOr<SQL::Value> decode(Decoder&);
LibSQL: Add an IPC encoder/decoder for SQL::Value This will allow clients to send placeholder values for prepared statements over IPC.
2022-12-01 22:29:17 -05:00
}
Reference in a new issue Copy permalink