Commit graph

13 commits

Author SHA1 Message Date
Timothy Flynn
53f8d62ea4 LibSQL: Partially implement the UPDATE command
This implements enough to update rows filtered by a WHERE clause.
2022-12-07 13:09:00 +01:00
Linus Groh
6e19ab2bbc 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-06 08:54:33 +01:00
Timothy Flynn
4b70908dc4 LibSQL+SQLServer: Return a NonnullRefPtr from Database::get_table
Database::get_table currently either returns a RefPtr to an existing
table, a nullptr if the table doesn't exist, or an Error if some
internal error occured. Change this to return a NonnullRefPtr to an
exisiting table, or a SQL::Result with any error, including if the
table was not found. Callers can then handle that specific error code
if they want.

Returning a NonnullRefPtr will enable some further cleanup. This had
some fallout of needing to change some other methods' return types from
AK::ErrorOr to SQL::Result so that TRY may continue to be used.
2022-11-30 11:43:13 +01:00
Timothy Flynn
c0b54f18b5 LibSQL: Copy SQL::Value instances less frequently (which may be vectors) 2022-10-14 17:47:44 +03:30
Timothy Flynn
df2ddcafd4 LibSQL: Remove the now-unused ExecutionContext::result object
The INSERT and SELECT statements set up this object for any expression
evaluation to indicate errors. This is no longer needed.
2022-02-10 23:11:13 +01:00
Timothy Flynn
f3c6cb40d7 LibSQL: Convert SQL expression evaluation to use ResultOr
Instead of setting an error in the execution context, we can directly
return that error or the successful value. This lets all callers, who
were already TRY-capable, simply TRY the expression evaluation.
2022-02-10 23:11:13 +01:00
Timothy Flynn
2397836f8e LibSQL+SQLServer: Introduce and use ResultOr<ValueType>
The result of a SQL statement execution is either:
    1. An error.
    2. The list of rows inserted, deleted, selected, etc.

(2) is currently represented by a combination of the Result class and
the ResultSet list it holds. This worked okay, but issues start to
arise when trying to use Result in non-statement contexts (for example,
when introducing Result to SQL expression execution).

What we really need is for Result to be a thin wrapper that represents
both (1) and (2), and to not have any explicit members like a ResultSet.
So this commit removes ResultSet from Result, and introduces ResultOr,
which is just an alias for AK::ErrorOrr. Statement execution now returns
ResultOr<ResultSet> instead of Result. This further opens the door for
expression execution to return ResultOr<Value> in the future.

Lastly, this moves some other context held by Result over to ResultSet.
This includes the row count (which is really just the size of ResultSet)
and the command for which the result is for.
2022-02-10 23:11:13 +01:00
Timothy Flynn
6620f19979 LibSQL+SQLServer: Return the new Result class from statement executions
We can now TRY anything that returns a SQL::Result or an AK::Error.
2022-02-10 12:20:35 +00:00
Jan de Visser
001949d77a LibSQL: Improve error handling
The handling of filesystem level errors was basically non-existing or
consisting of `VERIFY_NOT_REACHED` assertions. Addressed this by
* Adding `open` methods to `Heap` and `Database` which return errors.
* Changing the interface of methods of these classes and clients
downstream to propagate these errors.

The constructors of `Heap` and `Database` don't open the underlying
filesystem file anymore.

The SQL statement handlers return an `SQLErrorCode::InternalError`
error code if an error comes back from the lower levels. Note that some
of these errors are things like duplicate index entry errors that should
be caught before the SQL layer attempts to actually update the database.

Added tests to catch attempts to open weird or non-existent files as
databases.

Finally, in between me writing this patch and submitting the PR the
AK::Result<Foo, Bar> template got deprecated in favour of ErrorOr<Foo>.
This resulted in more busywork.
2021-12-04 20:49:22 +03:30
Jan de Visser
9022cf99ff LibSQL: Add better error handling to evaluate and execute methods
There was a lot of `VERIFY_NOT_REACHED` error handling going on. Fixed
most of those.

A bit of a caveat is that after every `evaluate` call for expressions
that are part of a statement the error status of the `SQLResult` return
value must be called.
2021-10-25 12:59:42 +02:00
Mahmoud Mandour
0906e3c206 LibSQL: Check data types in INSERT statement parsing
Data types are now checked against the table data types. When multiple
rows are inserted at once, we check all rows to be matching W.R.T data
types. Only then we insert the rows.
2021-10-04 15:51:48 +02:00
Mahmoud Mandour
f390478127 LibSQL: Parse INSERT statement without column names
This adds the ability to parse SQL INSERT statements in the following
form:

    INSERT INTO schema.tablename VALUES (column1, column2, ...),
                                        (column1, column2, ...), ...
2021-10-04 15:51:48 +02:00
Jan de Visser
d074a601df LibSQL+SQLServer: Bare bones INSERT and SELECT statements
This patch provides very basic, bare bones implementations of the
INSERT and SELECT statements. They are *very* limited:
- The only variant of the INSERT statement that currently works is
   SELECT INTO schema.table (column1, column2, ....) VALUES
      (value11, value21, ...), (value12, value22, ...), ...
   where the values are literals.
- The SELECT statement is even more limited, and is only provided to
  allow verification of the INSERT statement. The only form implemented
  is: SELECT * FROM schema.table

These statements required a bit of change in the Statement::execute
API. Originally execute only received a Database object as parameter.
This is not enough; we now pass an ExecutionContext object which
contains the Database, the current result set, and the last Tuple read
from the database. This object will undoubtedly evolve over time.

This API change dragged SQLServer::SQLStatement into the patch.

Another API addition is Expression::evaluate. This method is,
unsurprisingly, used to evaluate expressions, like the values in the
INSERT statement.

Finally, a new test file is added: TestSqlStatementExecution, which
tests the currently implemented statements. As the number and flavour of
implemented statements grows, this test file will probably have to be
restructured.
2021-08-21 22:03:30 +02:00