Currently, when clients connect to SQL server, we inform them of any
errors opening the database via an asynchronous IPC. But we already know
about these errors before returning from the connect() IPC, so this
roundabout propagation is a bit unnecessary. Now if we fail to open the
database, we will simply not send back a valid connection ID.
Disconnect has a similar story. Rather than disconnecting and invoking
an asynchronous IPC to inform the client of the disconnect, make the
disconnect() IPC synchronous (because all it does is remove the database
from the map of open databases). Further, the only user of this command
is the SQL REPL when it wants to connect to a different database, so it
makes sense to block it. This did require moving a bit of logic around
in the REPL to accommodate this change.
In order to execute a prepared statement multiple times, and track each
execution's results, clients will need to be provided an execution ID.
This will create a monotonically increasing ID each time a prepared
statement is executed for this purpose.
When storing IDs and sending values over IPC, this changes SQLServer to:
1. Stop using -1 as a nominal "bad" ID. Store the IDs as unsigned, and
use Optional in the one place that the IPC needs to indicate an ID
was not allocated.
2. Let LibIPC encode/decode enumerations (SQLErrorCode) on our behalf.
3. Use size_t for array sizes.
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 :^)
Rename sql_statement to prepare_statement and statement_execute to
execute_statement. The former aligns more with other database libraries
(e.g. Java's JDBC prepareStatement). The latter reads less awkwardly.
This patch introduces the SQLServer system server. This service is
supposed to be the only process/application talking to database storage.
This makes things like locking and caching more reliable, easier to
implement, and more efficient.
In LibSQL we added a client component that does the ugly IPC nitty-
gritty for you. All that's needed is setting a number of event handler
lambdas and you can connect to databases and execute statements on them.
Applications that wish to use this SQLClient class obviously need to
link LibSQL and LibIPC.
