[D1] Cleaning up Build with D1

public/_redirects

@@ -259,6 +259,7 @@
 
 # D1
 /d1/client-api/ /d1/build-with-d1/d1-client-api/ 301
+/d1/build-with-d1/d1-client-api/ /d1/worker-api/ 301
 /d1/learning/using-d1-from-pages/ /pages/functions/bindings/#d1-databases 301
 /d1/learning/debug-d1/ /d1/observability/debug-d1/ 301
 /d1/learning/using-indexes/ /d1/build-with-d1/use-indexes/ 301

src/content/changelogs/d1.yaml

@@ -19,7 +19,7 @@ entries:
   - publish_date: "2024-07-26"
     title: Fixed bug in TypeScript typings for run() API
     description: |-
-      The `run()` method as part of the [D1 Client API](/d1/build-with-d1/d1-client-api/) had an incorrect (outdated) type definition, which has now been addressed as of [`@cloudflare/workers-types`](https://www.npmjs.com/package/@cloudflare/workers-types) version `4.20240725.0`.
+      The `run()` method as part of the [D1 Client API](/d1/worker-api/) had an incorrect (outdated) type definition, which has now been addressed as of [`@cloudflare/workers-types`](https://www.npmjs.com/package/@cloudflare/workers-types) version `4.20240725.0`.
 
       The correct type definition is `stmt.run<T>(): D1Result`, as `run()` returns the result rows of the query. The previously _incorrect_ type definition was `stmt.run(): D1Response`, which only returns query metadata and no results.
 
@@ -28,7 +28,7 @@ entries:
     description: |-
       Previously, D1's [HTTP API](/api/operations/cloudflare-d1-query-database) returned a HTTP `500 Internal Server` error for queries that came in while a D1 database was overloaded. These requests now correctly return a `HTTP 429 Too Many Requests` error.
 
-      D1's [Workers API](/d1/build-with-d1/d1-client-api/) is unaffected by this change.
+      D1's [Workers API](/d1/worker-api/) is unaffected by this change.
 
   - publish_date: "2024-04-30"
     title: D1 alpha databases will stop accepting live SQL queries on August 15, 2024
@@ -42,7 +42,7 @@ entries:
     description: |-
       Previously, D1's [HTTP API](/api/operations/cloudflare-d1-query-database) returned a HTTP `500 Internal Server` error for an invalid query. An invalid SQL query now correctly returns a `HTTP 400 Bad Request` error.
 
-      D1's [Workers API](/d1/build-with-d1/d1-client-api/) is unaffected by this change.
+      D1's [Workers API](/d1/worker-api/) is unaffected by this change.
 
   - publish_date: "2024-04-05"
     title: D1 alpha databases are deprecated
@@ -81,24 +81,24 @@ entries:
   - publish_date: "2024-02-16"
     title: API changes to `run()`
     description: |-
-      A previous change (made on 2024-02-13) to the `run()` [query statement method](/d1/build-with-d1/d1-client-api/#await-stmtrun) has been reverted.
+      A previous change (made on 2024-02-13) to the `run()` [query statement method](/d1/worker-api/prepared-statements/#run) has been reverted.
 
-      `run()` now returns a `D1Result`, including the result rows, matching its original behaviour prior to the change on 2024-02-13.
+      `run()` now returns a `D1Result`, including the result rows, matching its original behavior prior to the change on 2024-02-13.
 
-      Future change to `run()` to return a [`D1ExecResult`](/d1/build-with-d1/d1-client-api/#return-object), as originally intended and documented, will be gated behind a [compatibility date](/workers/configuration/compatibility-dates/) as to avoid breaking existing Workers relying on the way `run()` currently works.
+      Future change to `run()` to return a [`D1ExecResult`](/d1/worker-api/return-object/#d1execresult), as originally intended and documented, will be gated behind a [compatibility date](/workers/configuration/compatibility-dates/) as to avoid breaking existing Workers relying on the way `run()` currently works.
 
   - publish_date: "2024-02-13"
     title: API changes to `raw()`, `all()` and `run()`
     description: |-
-      D1's `raw()`, `all()` and `run()` [query statement methods](/d1/build-with-d1/d1-client-api/#query-statement-methods) have been updated to reflect their intended behaviour and improve compatibility with ORM libraries.
+      D1's `raw()`, `all()` and `run()` [query statement methods](/d1/worker-api/prepared-statements/) have been updated to reflect their intended behavior and improve compatibility with ORM libraries.
 
       `raw()` now correctly returns results as an array of arrays, allowing the correct handling of duplicate column names (such as when joining tables), as compared to `all()`, which is unchanged and returns an array of objects. To include an array of column names in the results when using `raw()`, use `raw({columnNames: true})`.
 
-      `run()` no longer incorrectly returns a `D1Result` and instead returns a [`D1ExecResult`](/d1/build-with-d1/d1-client-api/#return-object) as originally intended and documented.
+      `run()` no longer incorrectly returns a `D1Result` and instead returns a [`D1ExecResult`](/d1/worker-api/return-object/#d1execresult) as originally intended and documented.
 
       This may be a breaking change for some applications that expected `raw()` to return an array of objects.
 
-      Refer to [D1 client API](/d1/build-with-d1/d1-client-api/) to review D1's query methods, return types and TypeScript support in detail.
+      Refer to [D1 client API](/d1/worker-api/) to review D1's query methods, return types and TypeScript support in detail.
 
   - publish_date: "2024-01-18"
     title: Support for LIMIT on UPDATE and DELETE statements
@@ -140,7 +140,7 @@ entries:
     description: |-
       D1 now returns a count of `rows_written` and `rows_read` for every query executed, allowing you to assess the cost of query for both [pricing](/d1/platform/pricing/) and [index optimization](/d1/build-with-d1/use-indexes/) purposes.
 
-      The `meta` object returned in [D1's Client API](/d1/build-with-d1/d1-client-api/) contains a total count of the rows read (`rows_read`) and rows written (`rows_written`) by that query. For example, a query that performs a full table scan (for example, `SELECT * FROM users`) from a table with 5000 rows would return a `rows_read` value of `5000`:
+      The `meta` object returned in [D1's Client API](/d1/worker-api/return-object/#d1result) contains a total count of the rows read (`rows_read`) and rows written (`rows_written`) by that query. For example, a query that performs a full table scan (for example, `SELECT * FROM users`) from a table with 5000 rows would return a `rows_read` value of `5000`:
       ```json
       "meta": {
         "duration": 0.20472300052642825,
@@ -200,7 +200,7 @@ entries:
   - publish_date: "2023-06-12"
     title: Deprecating Error.cause
     description: |-
-      As of [`wrangler v3.1.1`](https://github.com/cloudflare/workers-sdk/releases/tag/wrangler%403.1.1) the [D1 client API](/d1/build-with-d1/d1-client-api/) now returns [detailed error messages](/d1/build-with-d1/d1-client-api/#errors) within the top-level `Error.message` property, and no longer requires developers to inspect the `Error.cause.message` property.
+      As of [`wrangler v3.1.1`](https://github.com/cloudflare/workers-sdk/releases/tag/wrangler%403.1.1) the [D1 client API](/d1/worker-api/) now returns [detailed error messages](/d1/observability/debug-d1/) within the top-level `Error.message` property, and no longer requires developers to inspect the `Error.cause.message` property.
 
       To facilitate a transition from the previous `Error.cause` behaviour, detailed error messages will continue to be populated within `Error.cause` as well as the top-level `Error` object until approximately July 14th, 2023. Future versions of both `wrangler` and the D1 client API will no longer populate `Error.cause` after this date.
   - publish_date: "2023-05-19"

src/content/docs/d1/build-with-d1/foreign-keys.mdx

@@ -16,7 +16,7 @@ By default, D1 enforces that foreign key constraints are valid within all querie
 
 ## Defer foreign key constraints
 
-When running a [query](/d1/build-with-d1/d1-client-api/), [migration](/d1/reference/migrations/) or [importing data](/d1/build-with-d1/import-export-data/) against a D1 database, there may be situations in which you need to disable foreign key validation during table creation or changes to your schema.
+When running a [query](/d1/worker-api/), [migration](/d1/reference/migrations/) or [importing data](/d1/build-with-d1/import-export-data/) against a D1 database, there may be situations in which you need to disable foreign key validation during table creation or changes to your schema.
 
 D1's foreign key enforcement is equivalent to SQLite's `PRAGMA foreign_keys = on` directive. Because D1 runs every query inside an implicit transaction, user queries cannot change this during a query or migration.
 
@@ -87,7 +87,7 @@ There are five actions you can set when defining the `ON UPDATE` and/or `ON DELE
 
 :::caution[CASCADE usage]
 
-Although `CASCADE` can be the desired behavior in some cases, deleting child rows across tables can have undesirable effects and/or result in unintended side effects for your users. 
+Although `CASCADE` can be the desired behavior in some cases, deleting child rows across tables can have undesirable effects and/or result in unintended side effects for your users.
 :::
 
 In the following example, deleting a user from the `users` table will delete all related rows in the `scores` table as you have defined `ON DELETE CASCADE`. Delete all related rows in the `scores` table if you do not want to retain the scores for any users you have deleted entirely. This might mean that *other* users can no longer look up or refer to scores that were still valid.
@@ -110,5 +110,5 @@ CREATE TABLE scores (
 ## Next Steps
 
 * Read the SQLite [`FOREIGN KEY`](https://www.sqlite.org/foreignkeys.html) documentation.
-* Learn how to [use the D1 client API](/d1/build-with-d1/d1-client-api/) from within a Worker.
+* Learn how to [use the D1 Workers Binding API](/d1/worker-api/) from within a Worker.
 * Understand how [database migrations work](/d1/reference/migrations/) with D1.

src/content/docs/d1/build-with-d1/import-export-data.mdx

@@ -69,7 +69,7 @@ The `_cf_KV` table is a reserved table used by D1's underlying storage system. I
 
 :::
 
-From here, you can now query our new table from our Worker [using the D1 client API](/d1/build-with-d1/d1-client-api/).
+From here, you can now query our new table from our Worker [using the D1 Workers Binding API](/d1/worker-api/).
 
 :::caution[Known limitations]
 
@@ -201,5 +201,5 @@ VALUES
 ## Next Steps
 
 - Read the SQLite [`CREATE TABLE`](https://www.sqlite.org/lang_createtable.html) documentation.
-- Learn how to [use the D1 client API](/d1/build-with-d1/d1-client-api/) from within a Worker.
+- Learn how to [use the D1 Workers Binding API](/d1/worker-api/) from within a Worker.
 - Understand how [database migrations work](/d1/reference/migrations/) with D1.

src/content/docs/d1/build-with-d1/query-json.mdx

@@ -19,7 +19,7 @@ This allows you to more precisely query over data and reduce the result set your
 
 ## Types
 
-JSON data is stored as a `TEXT` column in D1. JSON types follow the same [type conversion rules](/d1/build-with-d1/d1-client-api/#type-conversion) as D1 in general, including:
+JSON data is stored as a `TEXT` column in D1. JSON types follow the same [type conversion rules](/d1/worker-api/#type-conversion) as D1 in general, including:
 
 * A JSON null is treated as a D1 `NULL`.
 * A JSON number is treated as an `INTEGER` or `REAL`.
@@ -184,7 +184,7 @@ To replace an existing value, use `json_replace()`, which will overwrite an exis
 Use `json_each` to expand an array into multiple rows. This can be useful when composing a `WHERE column IN (?)` query over several values. For example, if you wanted to update a list of users by their integer `id`, use `json_each` to return a table with each value as a column called `value`:
 
 ```sql
-UPDATE users 
+UPDATE users
 SET last_audited = '2023-05-16T11:24:08+00:00'
 WHERE id IN (SELECT value FROM json_each('[183183, 13913, 94944]'))
 ```
@@ -208,7 +208,7 @@ key|value|type|id|fullkey|path
 2|94944|integer|3|$[2]|$
 ```
 
-You can use `json_each` with D1's [client API](/d1/build-with-d1/d1-client-api/) in a Worker by creating a statement and using `JSON.stringify` to pass an array as a [bound parameter](/d1/build-with-d1/d1-client-api/#parameter-binding):
+You can use `json_each` with [D1 Workers Binding API](/d1/worker-api/) in a Worker by creating a statement and using `JSON.stringify` to pass an array as a [bound parameter](/d1/worker-api/d1-database/#guidance):
 
 ```ts
 const stmt = context.env.DB

src/content/docs/d1/examples/d1-and-hono.mdx

@@ -19,7 +19,7 @@ Hono is a fast web framework for building API-first applications, and it include
 When using Workers:
 
 * Ensure you have configured [`wrangler.toml`](/d1/get-started/#3-bind-your-worker-to-your-d1-database) to bind your D1 database to your Worker.
-* You can access your D1 databases via Hono's [`Context`](https://hono.dev/api/context) parameter: [bindings](https://hono.dev/getting-started/cloudflare-workers#bindings) are exposed on `context.env`. If you configured a [binding](/pages/functions/bindings/#d1-databases) named `DB`, then you would access D1's [client API](/d1/build-with-d1/d1-client-api/#query-statement-methods) methods via `c.env.DB`.
+* You can access your D1 databases via Hono's [`Context`](https://hono.dev/api/context) parameter: [bindings](https://hono.dev/getting-started/cloudflare-workers#bindings) are exposed on `context.env`. If you configured a [binding](/pages/functions/bindings/#d1-databases) named `DB`, then you would access [D1 Workers Binding API](/d1/worker-api/prepared-statements/) methods via `c.env.DB`.
 * Refer to the Hono documentation for [Cloudflare Workers](https://hono.dev/getting-started/cloudflare-workers).
 
 If you are using [Pages Functions](/pages/functions/):

src/content/docs/d1/examples/d1-and-remix.mdx

@@ -25,7 +25,7 @@ To set up a new Remix site on Cloudflare Pages that can query D1:
 The following example shows you how to define a Remix [`loader`](https://remix.run/docs/en/main/route/loader) that has a binding to a D1 database.
 
 * Bindings are passed through on the `context.env` parameter passed to a `LoaderFunction`.
-* If you configured a [binding](/pages/functions/bindings/#d1-databases) named `DB`, then you would access D1's [client API](/d1/build-with-d1/d1-client-api/#query-statement-methods) methods via `context.env.DB`.
+* If you configured a [binding](/pages/functions/bindings/#d1-databases) named `DB`, then you would access [D1 Workers Binding API](/d1/worker-api/prepared-statements/) methods via `context.env.DB`.
 
 <Tabs> <TabItem label="TypeScript" icon="seti:typescript">
 

src/content/docs/d1/examples/query-d1-from-python-workers.mdx

@@ -120,5 +120,5 @@ If you receive an error deploying:
 ## Next steps
 
 - Refer to [Workers Python documentation](/workers/languages/python/) to learn more about how to use Python in Workers.
-- Review the [D1 client API](/d1/build-with-d1/d1-client-api/) and how to query D1 databases.
+- Review the [D1 Workers Binding API](/d1/worker-api/) and how to query D1 databases.
 - Learn [how to import data](/d1/build-with-d1/import-export-data/) to your D1 database.

src/content/docs/d1/get-started.mdx

@@ -187,14 +187,12 @@ You create bindings by updating your `wrangler.toml` file.
 
    - The value (string) you set for `binding` is the **binding name**, and is used to reference this database in your Worker. In this tutorial, name your binding `DB`.
    - The binding name must be [a valid JavaScript variable name](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Grammar_and_types#variables). For example, `binding = "MY_DB"` or `binding = "productionDB"` would both be valid names for the binding.
-   - Your binding is available in your Worker at `env.<BINDING_NAME>` and the D1 [client API](/d1/build-with-d1/d1-client-api/) is exposed on this binding.
+   - Your binding is available in your Worker at `env.<BINDING_NAME>` and the D1 [Workers Binding API](/d1/worker-api/) is exposed on this binding.
 
 </Steps>
 
 :::note
-
-When you execute the `wrangler d1 create` command, the client API package (which implements the D1 API and database class) is automatically installed. For more information on the D1 Client API, refer to [D1 Client API](/d1/build-with-d1/d1-client-api/).
-
+When you execute the `wrangler d1 create` command, the client API package (which implements the D1 API and database class) is automatically installed. For more information on the D1 Workers Binding API, refer to [Workers Binding API](/d1/worker-api/).
 :::
 
 You can also bind your D1 database to a [Pages Function](/pages/functions/). For more information, refer to [Functions Bindings for D1](/pages/functions/bindings/#d1-databases).
@@ -336,7 +334,7 @@ After you have set up your database, run an SQL query from within your Worker.
     In the code above, you:
 
     1. Define a binding to your D1 database in your TypeScript code. This binding matches the `binding` value you set in `wrangler.toml` under `[[d1_databases]]`.
-    2. Query your database using `env.DB.prepare` to issue a [prepared query](/d1/build-with-d1/d1-client-api/) with a placeholder (the `?` in the query).
+    2. Query your database using `env.DB.prepare` to issue a [prepared query](/d1/worker-api/d1-database/#prepare) with a placeholder (the `?` in the query).
     3. Call `bind()` to safely and securely bind a value to that placeholder. In a real application, you would allow a user to define the `CompanyName` they want to list results for. Using `bind()` prevents users from executing arbitrary SQL (known as "SQL injection") against your application and deleting or otherwise modifying your database.
     4. Execute the query by calling `all()` to return all rows (or none, if the query returns none).
     5. Return your query results, if any, in JSON format with `Response.json(results)`.

src/content/docs/d1/index.mdx

@@ -25,7 +25,7 @@ Create new serverless SQL databases to query from your Workers and Pages project
 
 D1 is Cloudflare’s native serverless database. D1 allows you to build applications that handle large amounts of users at no extra cost. With D1, you can restore your database to any minute within the last 30 days.
 
-Create your first D1 database by [following the Get started guide](/d1/get-started/), learn how to [import data into a database](/d1/build-with-d1/import-export-data/), and how to [interact with your database](/d1/build-with-d1/d1-client-api/) directly from [Workers](/workers/) or [Pages](/pages/functions/bindings/#d1-databases).
+Create your first D1 database by [following the Get started guide](/d1/get-started/), learn how to [import data into a database](/d1/build-with-d1/import-export-data/), and how to [interact with your database](/d1/worker-api/) directly from [Workers](/workers/) or [Pages](/pages/functions/bindings/#d1-databases).
 
 ***
 
@@ -38,7 +38,7 @@ Create your first D1 database, establish a schema, import data and query D1 dire
 
 </Feature>
 
-<Feature header="SQLite" href="/d1/build-with-d1/d1-client-api/" cta="Execute SQL queries">
+<Feature header="SQLite" href="/d1/sql-api/sql-statements/" cta="Execute SQL queries">
 
 Execute SQL with SQLite's SQL compatibility and D1 Client API.