Stowage/ladybird
2
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-10-19 15:43:20 +00:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Libraries/LibDatabase/Database.h

62 lines
1.7 KiB
C
Raw Normal View History

Browser: Store cookies in a LibSQL database :^) Currently, cookies are ephemeral and only survive for the lifetime of Browser instance. This will make Browser instead store cookies in a SQL database for persisted access.
2022-10-27 12:56:22 -04:00
/*
LibDatabase+LibWebView: Extract our SQLite wrapper to its own library It currently lives in LibWebView as it was only used for cookies and local storage, both of which are managed in the UI process. Let's move it to its own library now to allow other processes to use it, without having to depend on LibWebView (and therefore LibWeb).
2025-10-07 14:35:22 -04:00
* Copyright (c) 2022-2025, Tim Flynn <trflynn89@ladybird.org>
Meta: Update my email address everywhere
2024-11-01 12:14:53 +01:00
* Copyright (c) 2023, Jelle Raaijmakers <jelle@ladybird.org>
Browser: Store cookies in a LibSQL database :^) Currently, cookies are ephemeral and only survive for the lifetime of Browser instance. This will make Browser instead store cookies in a SQL database for persisted access.
2022-10-27 12:56:22 -04:00
*
* SPDX-License-Identifier: BSD-2-Clause
*/
#pragma once
#include <AK/Error.h>
#include <AK/Function.h>
#include <AK/NonnullRefPtr.h>
#include <AK/RefCounted.h>
#include <AK/StringView.h>
#include <AK/Vector.h>
LibDatabase+LibWebView: Extract our SQLite wrapper to its own library It currently lives in LibWebView as it was only used for cookies and local storage, both of which are managed in the UI process. Let's move it to its own library now to allow other processes to use it, without having to depend on LibWebView (and therefore LibWeb).
2025-10-07 14:35:22 -04:00
#include <LibDatabase/Forward.h>
LibWebView: Replace usage of LibSQL with sqlite3 This makes WebView::Database wrap around sqlite3 instead of LibSQL. The effect on outside callers is pretty minimal. The main consequences are: 1. We must ensure the Cookie table exists before preparing any SQL statements involving that table. 2. We can use an INSERT OR REPLACE statement instead of separate INSERT and UPDATE statements.
2024-06-04 16:34:32 -04:00
struct sqlite3;
struct sqlite3_stmt;
Browser: Store cookies in a LibSQL database :^) Currently, cookies are ephemeral and only survive for the lifetime of Browser instance. This will make Browser instead store cookies in a SQL database for persisted access.
2022-10-27 12:56:22 -04:00
LibDatabase+LibWebView: Extract our SQLite wrapper to its own library It currently lives in LibWebView as it was only used for cookies and local storage, both of which are managed in the UI process. Let's move it to its own library now to allow other processes to use it, without having to depend on LibWebView (and therefore LibWeb).
2025-10-07 14:35:22 -04:00
namespace Database {
Browser: Store cookies in a LibSQL database :^) Currently, cookies are ephemeral and only survive for the lifetime of Browser instance. This will make Browser instead store cookies in a SQL database for persisted access.
2022-10-27 12:56:22 -04:00
LibDatabase+LibWebView: Extract our SQLite wrapper to its own library It currently lives in LibWebView as it was only used for cookies and local storage, both of which are managed in the UI process. Let's move it to its own library now to allow other processes to use it, without having to depend on LibWebView (and therefore LibWeb).
2025-10-07 14:35:22 -04:00
class DATABASE_API Database : public RefCounted<Database> {
Browser: Store cookies in a LibSQL database :^) Currently, cookies are ephemeral and only survive for the lifetime of Browser instance. This will make Browser instead store cookies in a SQL database for persisted access.
2022-10-27 12:56:22 -04:00
public:
LibDatabase+LibWebView: Extract our SQLite wrapper to its own library It currently lives in LibWebView as it was only used for cookies and local storage, both of which are managed in the UI process. Let's move it to its own library now to allow other processes to use it, without having to depend on LibWebView (and therefore LibWeb).
2025-10-07 14:35:22 -04:00
static ErrorOr<NonnullRefPtr<Database>> create(ByteString const& directory, StringView name);
LibWebView: Replace usage of LibSQL with sqlite3 This makes WebView::Database wrap around sqlite3 instead of LibSQL. The effect on outside callers is pretty minimal. The main consequences are: 1. We must ensure the Cookie table exists before preparing any SQL statements involving that table. 2. We can use an INSERT OR REPLACE statement instead of separate INSERT and UPDATE statements.
2024-06-04 16:34:32 -04:00
~Database();
using OnResult = Function<void(StatementID)>;
Browser: Store cookies in a LibSQL database :^) Currently, cookies are ephemeral and only survive for the lifetime of Browser instance. This will make Browser instead store cookies in a SQL database for persisted access.
2022-10-27 12:56:22 -04:00
LibWebView: Replace usage of LibSQL with sqlite3 This makes WebView::Database wrap around sqlite3 instead of LibSQL. The effect on outside callers is pretty minimal. The main consequences are: 1. We must ensure the Cookie table exists before preparing any SQL statements involving that table. 2. We can use an INSERT OR REPLACE statement instead of separate INSERT and UPDATE statements.
2024-06-04 16:34:32 -04:00
ErrorOr<StatementID> prepare_statement(StringView statement);
void execute_statement(StatementID, OnResult on_result);
Browser: Store cookies in a LibSQL database :^) Currently, cookies are ephemeral and only survive for the lifetime of Browser instance. This will make Browser instead store cookies in a SQL database for persisted access.
2022-10-27 12:56:22 -04:00
template<typename... PlaceholderValues>
LibWebView: Replace usage of LibSQL with sqlite3 This makes WebView::Database wrap around sqlite3 instead of LibSQL. The effect on outside callers is pretty minimal. The main consequences are: 1. We must ensure the Cookie table exists before preparing any SQL statements involving that table. 2. We can use an INSERT OR REPLACE statement instead of separate INSERT and UPDATE statements.
2024-06-04 16:34:32 -04:00
void execute_statement(StatementID statement_id, OnResult on_result, PlaceholderValues&&... placeholder_values)
Browser: Store cookies in a LibSQL database :^) Currently, cookies are ephemeral and only survive for the lifetime of Browser instance. This will make Browser instead store cookies in a SQL database for persisted access.
2022-10-27 12:56:22 -04:00
{
LibWebView: Replace usage of LibSQL with sqlite3 This makes WebView::Database wrap around sqlite3 instead of LibSQL. The effect on outside callers is pretty minimal. The main consequences are: 1. We must ensure the Cookie table exists before preparing any SQL statements involving that table. 2. We can use an INSERT OR REPLACE statement instead of separate INSERT and UPDATE statements.
2024-06-04 16:34:32 -04:00
int index = 1;
(apply_placeholder(statement_id, index++, forward<PlaceholderValues>(placeholder_values)), ...);
Browser: Synchronize database statements used for cookies Since SQLServer is inherently asynchronous, database statements can run in parallel. Our `CookieJar` did not require synchronous actions on the database for its cookies, resulting in cookies not being set immediately. This resulted in a bug that could be exposed by setting `document.cookie` and immediately querying its value, revealing that the cookie was not yet persisted. Solve this by requiring all database statements to be executed synchronously. Ideally SQLServer has a mechanism to determine interquery dependencies and blocks until dependent queries are fully executed, but until we have that, this works around that limitation.
2023-08-07 23:33:01 +02:00
LibWebView: Replace usage of LibSQL with sqlite3 This makes WebView::Database wrap around sqlite3 instead of LibSQL. The effect on outside callers is pretty minimal. The main consequences are: 1. We must ensure the Cookie table exists before preparing any SQL statements involving that table. 2. We can use an INSERT OR REPLACE statement instead of separate INSERT and UPDATE statements.
2024-06-04 16:34:32 -04:00
execute_statement(statement_id, move(on_result));
Browser: Store cookies in a LibSQL database :^) Currently, cookies are ephemeral and only survive for the lifetime of Browser instance. This will make Browser instead store cookies in a SQL database for persisted access.
2022-10-27 12:56:22 -04:00
}
LibWebView: Replace usage of LibSQL with sqlite3 This makes WebView::Database wrap around sqlite3 instead of LibSQL. The effect on outside callers is pretty minimal. The main consequences are: 1. We must ensure the Cookie table exists before preparing any SQL statements involving that table. 2. We can use an INSERT OR REPLACE statement instead of separate INSERT and UPDATE statements.
2024-06-04 16:34:32 -04:00
template<typename ValueType>
ValueType result_column(StatementID, int column);
Browser: Store cookies in a LibSQL database :^) Currently, cookies are ephemeral and only survive for the lifetime of Browser instance. This will make Browser instead store cookies in a SQL database for persisted access.
2022-10-27 12:56:22 -04:00
LibWebView: Replace usage of LibSQL with sqlite3 This makes WebView::Database wrap around sqlite3 instead of LibSQL. The effect on outside callers is pretty minimal. The main consequences are: 1. We must ensure the Cookie table exists before preparing any SQL statements involving that table. 2. We can use an INSERT OR REPLACE statement instead of separate INSERT and UPDATE statements.
2024-06-04 16:34:32 -04:00
private:
explicit Database(sqlite3*);
Browser: Store cookies in a LibSQL database :^) Currently, cookies are ephemeral and only survive for the lifetime of Browser instance. This will make Browser instead store cookies in a SQL database for persisted access.
2022-10-27 12:56:22 -04:00
LibWebView: Replace usage of LibSQL with sqlite3 This makes WebView::Database wrap around sqlite3 instead of LibSQL. The effect on outside callers is pretty minimal. The main consequences are: 1. We must ensure the Cookie table exists before preparing any SQL statements involving that table. 2. We can use an INSERT OR REPLACE statement instead of separate INSERT and UPDATE statements.
2024-06-04 16:34:32 -04:00
template<typename ValueType>
void apply_placeholder(StatementID statement_id, int index, ValueType const& value);
Browser: Store cookies in a LibSQL database :^) Currently, cookies are ephemeral and only survive for the lifetime of Browser instance. This will make Browser instead store cookies in a SQL database for persisted access.
2022-10-27 12:56:22 -04:00
LibWebView: Replace usage of LibSQL with sqlite3 This makes WebView::Database wrap around sqlite3 instead of LibSQL. The effect on outside callers is pretty minimal. The main consequences are: 1. We must ensure the Cookie table exists before preparing any SQL statements involving that table. 2. We can use an INSERT OR REPLACE statement instead of separate INSERT and UPDATE statements.
2024-06-04 16:34:32 -04:00
ALWAYS_INLINE sqlite3_stmt* prepared_statement(StatementID statement_id)
LibSQL+Userland: Pass SQL IPC results to clients in a structure SQLClient exists as a wrapper around SQL IPC to provide a bit friendlier interface for clients to deal with. Though right now, it mostly forwards values as-is from IPC to the clients. This makes it a bit verbose to add values to IPC responses, as we then have to add it to the callbacks used by all clients. It's also a bit confusing seeing a sea of "auto" as the parameter types for these callbacks. This patch moves these response values to named structures instead. This will allow adding values without needing to simultaneously update all clients. We can then separately handle the new values in interested clients only.
2023-02-03 10:33:10 -05:00
{
LibWebView: Replace usage of LibSQL with sqlite3 This makes WebView::Database wrap around sqlite3 instead of LibSQL. The effect on outside callers is pretty minimal. The main consequences are: 1. We must ensure the Cookie table exists before preparing any SQL statements involving that table. 2. We can use an INSERT OR REPLACE statement instead of separate INSERT and UPDATE statements.
2024-06-04 16:34:32 -04:00
VERIFY(statement_id < m_prepared_statements.size());
return m_prepared_statements[statement_id];
LibSQL+Userland: Pass SQL IPC results to clients in a structure SQLClient exists as a wrapper around SQL IPC to provide a bit friendlier interface for clients to deal with. Though right now, it mostly forwards values as-is from IPC to the clients. This makes it a bit verbose to add values to IPC responses, as we then have to add it to the callbacks used by all clients. It's also a bit confusing seeing a sea of "auto" as the parameter types for these callbacks. This patch moves these response values to named structures instead. This will allow adding values without needing to simultaneously update all clients. We can then separately handle the new values in interested clients only.
2023-02-03 10:33:10 -05:00
}
LibWebView: Replace usage of LibSQL with sqlite3 This makes WebView::Database wrap around sqlite3 instead of LibSQL. The effect on outside callers is pretty minimal. The main consequences are: 1. We must ensure the Cookie table exists before preparing any SQL statements involving that table. 2. We can use an INSERT OR REPLACE statement instead of separate INSERT and UPDATE statements.
2024-06-04 16:34:32 -04:00
sqlite3* m_database { nullptr };
Vector<sqlite3_stmt*> m_prepared_statements;
Browser: Store cookies in a LibSQL database :^) Currently, cookies are ephemeral and only survive for the lifetime of Browser instance. This will make Browser instead store cookies in a SQL database for persisted access.
2022-10-27 12:56:22 -04:00
};
}
Reference in a new issue Copy permalink