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.

1 files changed, 6 insertions, 4 deletions

diff --git a/Userland/Libraries/LibSQL/Row.h b/Userland/Libraries/LibSQL/Row.h
index 27c98339f0..25c6a8cab7 100644
--- a/Userland/Libraries/LibSQL/Row.h
+++ b/Userland/Libraries/LibSQL/Row.h
@@ -9,6 +9,7 @@
 #include <AK/ByteBuffer.h>
 #include <AK/RefPtr.h>
 #include <LibSQL/Forward.h>
+#include <LibSQL/Meta.h>
 #include <LibSQL/Value.h>
 
 namespace SQL {
@@ -26,16 +27,17 @@ class Row : public Tuple {
 public:
     Row();
     explicit Row(TupleDescriptor const&);
-    explicit Row(RefPtr<TableDef>);
-    Row(RefPtr<TableDef>, u32, ByteBuffer&);
+    explicit Row(RefPtr<TableDef>, u32 pointer = 0);
+    Row(RefPtr<TableDef>, u32, Serializer&);
     Row(Row const&) = default;
     virtual ~Row() override = default;
 
     [[nodiscard]] u32 next_pointer() const { return m_next_pointer; }
     void next_pointer(u32 ptr) { m_next_pointer = ptr; }
     RefPtr<TableDef> table() const { return m_table; }
-    virtual void serialize(ByteBuffer&) const override;
-    [[nodiscard]] virtual size_t data_length() const override { return Tuple::data_length() + sizeof(u32); }
+    [[nodiscard]] virtual size_t length() const override { return Tuple::length() + sizeof(u32); }
+    virtual void serialize(Serializer&) const override;
+    virtual void deserialize(Serializer&) override;
 
 protected:
     void copy_from(Row const&);