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

132 lines
3.9 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
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: 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>
namespace SQL {
/**
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 {
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(int);
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
explicit Value(u32);
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: Rewrite the SQL::Value type to be contained within one class Currently, the Value class is essentially a "pImpl" wrapper around the ValueImpl hierarchy of classes. This is a bit difficult to follow and reason about, as methods jump between the Value class and its impl classes. This changes the Variant held by Value to instead store the specified types (String, int, etc.) directly. In doing so, the ValueImpl classes are removed, and all methods are now just concise Variant visitors. As part of this rewrite, support for the "array" type is dropped (or rather, just not re-implemented) as it was unused. If it's needed in the future, support can be re-added. This does retain the ability for non-NULL types to store NULL values (i.e. an empty Optional). I 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<Value> create_tuple(NonnullRefPtr<TupleDescriptor>);
static ResultOr<Value> create_tuple(Vector<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: Rewrite the SQL::Value type to be contained within one class Currently, the Value class is essentially a "pImpl" wrapper around the ValueImpl hierarchy of classes. This is a bit difficult to follow and reason about, as methods jump between the Value class and its impl classes. This changes the Variant held by Value to instead store the specified types (String, int, etc.) directly. In doing so, the ValueImpl classes are removed, and all methods are now just concise Variant visitors. As part of this rewrite, support for the "array" type is dropped (or rather, just not re-implemented) as it was unused. If it's needed in the future, support can be re-added. This does retain the ability for non-NULL types to store NULL values (i.e. an empty Optional). I 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<typename T>
requires(SameAs<RemoveCVReference<T>, bool>) explicit Value(T value)
: 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: Rewrite the SQL::Value type to be contained within one class Currently, the Value class is essentially a "pImpl" wrapper around the ValueImpl hierarchy of classes. This is a bit difficult to follow and reason about, as methods jump between the Value class and its impl classes. This changes the Variant held by Value to instead store the specified types (String, int, etc.) directly. In doing so, the ValueImpl classes are removed, and all methods are now just concise Variant visitors. As part of this rewrite, support for the "array" type is dropped (or rather, just not re-implemented) as it was unused. If it's needed in the future, support can be re-added. This does retain the ability for non-NULL types to store NULL values (i.e. an empty Optional). I 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: 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<int> to_int() const;
[[nodiscard]] Optional<u32> to_u32() const;
[[nodiscard]] Optional<double> to_double() const;
[[nodiscard]] Optional<bool> to_bool() const;
[[nodiscard]] Optional<Vector<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
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=(int);
Value& operator=(u32);
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
ResultOr<void> assign_tuple(NonnullRefPtr<TupleDescriptor>);
ResultOr<void> assign_tuple(Vector<Value>);
template<typename T>
requires(SameAs<RemoveCVReference<T>, bool>) Value& operator=(T value)
{
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==(int) 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==(u32) 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;
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;
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: 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;
};
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
using ValueType = Variant<DeprecatedString, int, 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
}
};
Reference in a new issue Copy permalink