diff --git a/docs/content/sips/013-sqlite.md b/docs/content/sips/013-sqlite.md index adeb2014e7..3a7780f168 100644 --- a/docs/content/sips/013-sqlite.md +++ b/docs/content/sips/013-sqlite.md @@ -65,11 +65,8 @@ variant error { // `error::no-such-database` will be raised if the `name` is not recognized. open: func(name: string) -> expected -// Execute a statement -execute: func(conn: connection, statement: string, parameters: list) -> expected - -// Query data -query: func(conn: connection, query: string, parameters: list) -> expected +// Execute a statement returning back data if there is any +execute: func(conn: connection, statement: string, parameters: list) -> expected // Close the specified `connection`. close: func(conn: connection) @@ -99,12 +96,9 @@ variant value { *Note: the pseudo-resource design was inspired by the interface of similar functions in [WASI preview 2](https://github.com/bytecodealliance/preview2-prototyping/blob/d56b8977a2b700432d1f7f84656d542f1d8854b0/wit/wasi.wit#L772-L794).* -#### Interface open questions +The interface only contains an `execute` function. Earlier iterations also included a `query` function. However, `query` and `execute` served very similar roles and had extremely similar implementations. Since adding functions is much easier than taking them away, we have decided to only have an `execute` function to begin with. This `execute` function executes any statement whether it is a query or some sort of database management statement. -**TODO**: answer these questions -* `row-result` can be very large. Should we provide some paging mechanism or a different API that allows for reading subsets of the returned data? - * Crossing the wit boundary could potentially be expensive if the results are large enough. Giving the user control of how they read that data could be helpful. -* Is there really a need for query *and* execute functions since at the end of the day, they are basically equivalent? +In the future, we may want to bring back a `query` function that allows the user to "page" through their results (instead of receiving all results in a single - potentially very large - collection). This will avoid some of the performance constraints of the current interface where large `query-result`s could lead to memory issues in constrained environments. #### Database migrations