Conversation
ebenezerdon
requested review from
ItzNotABug,
abnegate,
adityaoberai,
dennisivy and
tessamero
Website (appwrite/website)Project ID: Tip JWT tokens let functions act on behalf of users while preserving their permissions |
|
@ebenezerdon I was looking through #2134 and looks like we have a different syntax for the row operations via the Tables API, so we may need to update all technical examples (particularly, to use the Tables object instead of the Databases object). |
Oh thanks. Let me check with Darshan |
|
The preview deployment failed. 🔴 Last updated at: 2025-08-20 18:54:55 CET |
WalkthroughThis pull request updates terminology and API usage across many documentation and blog post files to reflect Appwrite's Tables model. Changes replace Databases/Collections/Documents/Attributes with TablesDB/Tables/Rows/Columns, update imports and constructors (Databases → TablesDB), rename identifiers (collectionId → tableId, documentId → rowId), and adjust method names and response shapes (listDocuments → listRows, createDocument → createRow, response.documents → response.rows). Some examples also change call signatures (positional ↔ object forms) and a few non‑terminology signature tweaks appear (e.g., Functions.createExecution argument shape). Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Areas requiring extra attention:
Pre-merge checks and finishing touches✅ Passed checks (3 passed)
✨ Finishing touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 44
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (32)
src/routes/blog/post/product-update-jan-2025/+page.markdoc (2)
44-46: Section heading is incorrect (duplicate of previous section).This header says “The Appwrite Partners program” again, but the section content and image are about the Scale plan.
-# The Appwrite Partners program +# The Appwrite Scale plan
56-56: Fix typo in alt text: “Notfications” → “Notifications”.User-facing copy and accessibility text should be error-free.
- +src/routes/blog/post/open-source-firebase-alternative/+page.markdoc (1)
61-77: Correct Storage descriptions to remove “rows”
Storage should reference files only, not database rows.
- src/routes/blog/post/open-source-firebase-alternative/+page.markdoc (line 63): change “images, videos, rows, and other project files” → “images, videos, and other project files”
- src/routes/docs/products/storage/+page.markdoc (line 8): change “images, videos, rows, and other files” → “images, videos, and other files”
src/routes/blog/post/cors-error/+page.markdoc (1)
41-45: Fix inconsistency: “Bad ID on request” vs “Incorrect ID on request”The list entry (Line 43) doesn’t match the section heading. Unify to avoid confusion.
-3. Bad ID on request +3. Incorrect ID on requestAlso applies to: 63-64
src/routes/blog/post/open-source-vercel-alternative/+page.markdoc (1)
220-220: Broken docs path: “/doc/” → “/docs/”.This link likely 404s; fix before publishing.
-- [Appwrite Sites docs](/doc/products/sites) +- [Appwrite Sites docs](/docs/products/sites)src/routes/blog/post/improve-devex-dev-keys/+page.markdoc (1)
36-41: Table permissions currently block row creation. Set “Any → Create: True” for this demo.With all “Any” permissions set to False, unauthenticated clients cannot create rows; you’ll see 401/403 instead of 429. For this rate‑limit demo, allow table‑level Create.
| | Create | Read | Update | Delete | | --- | --- | --- | --- | --- | -| Any | False | False | False | False | +| Any | True | False | False | False |Docs: Users must be granted Create at the table level to create rows. (appwrite.io)
src/routes/blog/post/offline-first-journal/+page.markdoc (3)
193-216: Replace non-existent db.addTables with db.addCollections; fix misleading comment.RxDB exposes addCollections, not addTables. Local DB name doesn’t need to match the Appwrite database ID. (rxdb.info)
- // Add tables - await db.addTables({ - entries: { // Name must match the table ID from Appwrite + // Add collections + await db.addCollections({ + entries: { // Local collection name (can differ from Appwrite table ID) schema: journalSchema } });Also adjust the database name comment:
- name: 'journals', // Name must match the database ID from Appwrite + name: 'journals', // Local DB name (does not have to match the Appwrite database ID)
326-326: Fix import path: file is created as lib/databases.js, but imports use “database”.This will 404 at runtime. Unify to lib/databases.js.
-import { getJournals } from '$lib/database'; +import { getJournals } from '$lib/databases.js';-import { getJournals, deleteJournal } from '$lib/database.js'; +import { getJournals, deleteJournal } from '$lib/databases.js';-import { deleteJournal, getJournal } from '$lib/database.js'; +import { deleteJournal, getJournal } from '$lib/databases.js';-import { updateJournal, getJournal } from '$lib/database.js'; +import { updateJournal, getJournal } from '$lib/databases.js';-import { createJournal } from '$lib/database.js'; +import { createJournal } from '$lib/databases.js';Also applies to: 349-349, 438-438, 531-531, 654-654
355-363: Undefined function loadJournals() used after delete.Define it to refresh state after deletions.
async function handleDelete(id) { if (confirm('Are you sure you want to delete this journal entry?')) { try { await deleteJournal(id); await loadJournals(); } catch (err) { error = err.message; } } } function formatDate(timestamp) { return new Date(timestamp).toLocaleString(); } + + async function loadJournals() { + try { + journals = await getJournals(); + } catch (err) { + error = err.message; + } + }src/routes/blog/post/product-update-september/+page.markdoc (1)
28-28: Fix typo in link text."annoucement" → "announcement".
-[Read the annoucement.](https://appwrite.io/blog/post/announcing-roles-for-enhanced-collaboration-and-security) +[Read the announcement.](https://appwrite.io/blog/post/announcing-roles-for-enhanced-collaboration-and-security)src/routes/blog/post/customer-stories-smartbee/+page.markdoc (1)
4-4: Fix country name in description.Should be “Colombia,” not “Columbia.”
-description: Learn how Smartbee leveraged Appwrite to build a performant and robust system to monitor and aggregate gas level data in real-time for 7 coal mines in Columbia. +description: Learn how Smartbee leveraged Appwrite to build a performant and robust system to monitor and aggregate gas level data in real-time for 7 coal mines in Colombia.src/routes/blog/post/announcing-go-support/+page.markdoc (1)
250-270: Fix missing comma in error return; ListRows signature confirmed.- return Context.Res.Text("Internal error" Context.Res.WithStatusCode(500)) + return Context.Res.Text("Internal error", Context.Res.WithStatusCode(500))ListRows is defined as
func (srv *TablesDB) ListRows(databaseId string, tableId string, optionalSetters ...ListRowsOption) (*models.RowList, error)so calling
tablesDB.ListRows("main", "profiles")is correct—no params struct needed.src/routes/blog/post/appwrite-1.5-now-available-on-cloud/+page.markdoc (1)
221-231: Fix syntax error and switch to object-arg formThere’s an extra closing brace (“}”) and the example should use the queries array.
-db.listRows( - '<DATABASE_ID>', - '<TABLE_ID>', - [ - Query.or([ - Query.contains('name','ivy'), - Query.greaterThan('age',30) - ]) - ] -}); +tablesDB.listRows({ + databaseId: '<DATABASE_ID>', + tableId: '<TABLE_ID>', + queries: [ + Query.or([ + Query.contains('name', ['ivy']), + Query.greaterThan('age', 30), + ]), + ], +});src/routes/blog/post/simplify-your-data-management-with-relationships/+page.markdoc (1)
85-93: JSON syntax error: missing comma after $tableId{ "$id": "642b9d627d866e646602", "$databaseId": "marvel", - "$tableId": "reviews" + "$tableId": "reviews", "$createdAt": "2023-04-04T03:45:38.514+00:00", "$updatedAt": "2023-04-04T03:45:38.514+00:00", "$permissions": [], "content": "Great movie" }src/routes/blog/post/ci-cd-examples-in-appwrite/+page.markdoc (1)
41-47: YAML indentation: replace tabs with spacesTabs can break GitHub Actions parsing. Use spaces.
-name: Sync Tables - -on: - release: - types: [ published ] +name: Sync Tables + +on: + release: + types: [published]src/routes/blog/post/how-to-optimize-your-appwrite-project/+page.markdoc (1)
44-63: Fix stray brace and use object-arg listRows for paginationThere’s an unmatched “}” and the examples should use the object form.
-const firstPage = await tablesDB.listRows( - '<DATABASE_ID>', - '<TABLE_ID>', - [ - Query.equal('author', 'Meredith Palmer'), - Query.limit(20), - Query.offset(0),// Fetch the first 20 records - ] -}) - -const secondPage = await tablesDB.listRows( - '<DATABASE_ID>', - '<TABLE_ID>', - [ - Query.equal('author', 'Meredith Palmer'), - Query.limit(20), - Query.offset(20), // Fetch the next 20 records - ] -}) +const firstPage = await tablesDB.listRows({ + databaseId: '<DATABASE_ID>', + tableId: '<TABLE_ID>', + queries: [Query.equal('author', ['Meredith Palmer']), Query.limit(20), Query.offset(0)], +}); + +const secondPage = await tablesDB.listRows({ + databaseId: '<DATABASE_ID>', + tableId: '<TABLE_ID>', + queries: [Query.equal('author', ['Meredith Palmer']), Query.limit(20), Query.offset(20)], +});src/routes/blog/post/announcing-auto-increment-support/+page.markdoc (1)
52-59: Fix stray closing brace in code sample.The extra
}afterlistRows(...)breaks the snippet.tablesDB.listRows( '<DATABASE_ID>', '<TABLE_ID>', [ Query.orderAsc('$sequence'), ] -}); +);src/routes/blog/post/announcing-bulk-api/+page.markdoc (1)
55-71: Node example should use object-arg shape, not positional.
node-appwritemethods accept a single object. The current snippet will mislead users.-const result = await tablesDB.createRows( - '<DATABASE_ID>', - '<TABLE_ID>', - [ - { - $id: sdk.ID.unique(), - name: 'Row 1', - }, - { - $id: sdk.ID.unique(), - name: 'Row 2', - } - ] -); +const result = await tablesDB.createRows({ + databaseId: '<DATABASE_ID>', + tableId: '<TABLE_ID>', + rows: [ + { $id: sdk.ID.unique(), name: 'Row 1' }, + { $id: sdk.ID.unique(), name: 'Row 2' }, + ], +});src/routes/blog/post/3-things-you-can-build-with-go-runtime/+page.markdoc (2)
221-246: Handle errors from create operations (DB/Table/Column).Silent failures make debugging hard and can break example flows.
- dbs.Create( + if _, err := dbs.Create( dbId, "URL Database", - ) + ); err != nil { + Context.Error(err) + return + } @@ - dbs.CreateTable( + if _, err := dbs.CreateTable( dbId, tableId, "URLs", dbs.WithCreateTablePermissions([]string{permission.Read("any")}), - ) + ); err != nil { + Context.Error(err) + return + } @@ - dbs.CreateUrlColumn( + if _, err := dbs.CreateUrlColumn( dbId, tableId, "longUrl", true, dbs.WithCreateUrlColumnArray(false), - ) + ); err != nil { + Context.Error(err) + return + }
273-279: Guard missing dynamic API key.Accessing
Context.Req.Headers["x-appwrite-key"]without validation can lead to an empty key and 401s later. Fail fast with a clear message.client := appwrite.NewClient( appwrite.WithEndpoint(os.Getenv("APPWRITE_FUNCTION_API_ENDPOINT")), appwrite.WithProject(os.Getenv("APPWRITE_FUNCTION_PROJECT_ID")), - appwrite.WithKey(Context.Req.Headers["x-appwrite-key"]), + // Prefer dynamic API Key header; return 401 if missing + appwrite.WithKey(func() string { + key := Context.Req.Headers["x-appwrite-key"] + return key + }()), ) +if Context.Req.Headers["x-appwrite-key"] == "" { + return Context.Res.Json(map[string]any{ + "ok": false, + "error": "Missing x-appwrite-key (dynamic API key). Enable it in Function Settings and pass it in the request.", + }, Context.Res.WithStatusCode(401)) +}src/routes/blog/post/announcing-atomic-numeric-operations/+page.markdoc (2)
56-63: Update placeholders to use <ROW_ID> (not <DOCUMENT_ID>).Terminology migrated to Tables/Rows; examples should reflect
<ROW_ID>.- '<DOCUMENT_ID>', + '<ROW_ID>',Also applies to: 76-83
43-45: Use correct TablesDB SDK methods for atomic operations
ReplaceincrementDocumentAttribute/decrementDocumentAttributewithincrementRowColumn/decrementRowColumnin prose and code examples (lines 43–45, 56–63, 76–83).src/routes/blog/post/appwrite-realtime-for-flutter/+page.markdoc (2)
180-185: Initialize Client with endpoint and fix placeholder inconsistency.Examples omit
setEndpointand use'delete'as a project ID; both will confuse readers and break connectivity.- initState() { + initState() { super.initState(); - client = Client().setProject('<PROJECT_ID>'); // your project id + client = Client() + .setEndpoint('https://<REGION>.cloud.appwrite.io/v1') // your API endpoint + .setProject('<PROJECT_ID>'); // your project ID } @@ - initState() { + initState() { super.initState(); - client = Client().setProject('delete'); // your project id + client = Client() + .setEndpoint('https://<REGION>.cloud.appwrite.io/v1') + .setProject('<PROJECT_ID>'); tablesDB = TablesDB(client); loadItems(); subscribe(); } @@ - initState() { + initState() { super.initState(); - client = Client().setProject('delete'); // your project id + client = Client() + .setEndpoint('https://<REGION>.cloud.appwrite.io/v1') + .setProject('<PROJECT_ID>'); tablesDB = TablesDB(client); loadItems(); subscribe(); }Also applies to: 205-213, 335-343
189-194: Dispose the TextEditingController to avoid leaks.Add
_nameController.dispose()indispose().dispose(){ - subscription?.close(); + subscription?.close(); + _nameController.dispose(); super.dispose(); }Also applies to: 384-388
src/routes/blog/post/ai-crystal-ball/+page.markdoc (1)
295-308: Syntax error in createRow call; fix and adopt object-args.
permissions:is not valid as a bare argument; must be part of the options object. Also switch to object-args.- return await tablesDB.createRow( - databaseId, - githubDataTableId, - userId, - { - username, - followers, - following, - languages - }, - permissions: [ - Permission.write(Role.user(userId)), Permission.read(Role.user(userId)) - ] - }) + return await tablesDB.createRow({ + databaseId, + tableId: githubDataTableId, + rowId: userId, + data: { username, followers, following, languages }, + permissions: [ + Permission.write(Role.user(userId)), + Permission.read(Role.user(userId)), + ], + })Object-args pattern reference. (appwrite.io)
src/routes/blog/post/building-init-giveaway-app/+page.markdoc (1)
105-115: Fix OAuthProvider import/export mismatch.appwrite.js no longer exports OAuthProvider, but user.js imports it from './appwrite'. Re-export it here to keep the snippet consistent.
import { Account, Client, TablesDB } from 'appwrite'; import { APPWRITE_ENDPOINT, APPWRITE_PROJECT } from './constants'; export const client = new Client(); client.setEndpoint(APPWRITE_ENDPOINT).setProject(APPWRITE_PROJECT); export const account = new Account(client); export const tablesDB = new TablesDB(client); +// Re-export to support: `import { account, OAuthProvider } from './appwrite'` +export { OAuthProvider } from 'appwrite';src/routes/blog/post/build-personal-crm-sveltekit/+page.markdoc (2)
26-34: Fix column types: phone and notes should be string-based.Integer will drop leading zeros and cannot hold freeform notes. Correct the table to avoid schema pain later.
-| phone | Integer | 25 | No | -| notes | Integer | 2000 | No | +| phone | String | 25 | No | +| notes | String | 2000 | No |
160-166: Fix route path mismatch: created /api/contact but UI calls /api/contacts.Either rename the route directory to
src/routes/api/contacts/+server.jsor update the fetch URLs below to singular.-const response = await fetch('/api/contacts'); +const response = await fetch('/api/contact');-const response = await fetch('/api/contacts', { +const response = await fetch('/api/contact', {-const response = await fetch('/api/contacts', { +const response = await fetch('/api/contact', {-const response = await fetch('/api/contacts', { +const response = await fetch('/api/contact', {Also applies to: 246-259, 304-311, 340-346, 371-379
src/routes/blog/post/best-pagination-technique/+page.markdoc (1)
269-275: Use the cursor variable in the REST example (cursor).The query uses offset instead of cursor. Fix the param.
-http.get(`${config.endpoint}/databases/main/tables/posts/rows?queries[]=${offset}&queries[]=${limit}`, { +http.get(`${config.endpoint}/databases/main/tables/posts/rows?queries[]=${cursor}&queries[]=${limit}`, {src/routes/blog/post/build-fullstack-svelte-appwrite/+page.markdoc (3)
193-210: ID is used but not imported in auth store.register() uses ID.unique() without importing ID, causing a ReferenceError at runtime.
import { writable } from 'svelte/store' import { account } from '$lib/appwrite' +import { ID } from 'appwrite'Also applies to: 232-245
258-265: Update deleteSession to object-arg signature.Recent SDKs use an object parameter; the positional form is deprecated.
- await account.deleteSession('current') + await account.deleteSession({ sessionId: 'current' })Reference: Appwrite Account API (Node/JS) shows deleteSession({ sessionId }). (appwrite.io)
652-662: TablesDB createRow: fix signature and rowId generation.Use object-args and ID.unique() instead of the string 'unique()'.
- await tablesDB.createRow( - DATABASE_ID, - EXPENSES_TABLE_ID, - 'unique()', - expenseData, - [ - Permission.read(Role.user(user.$id)), - Permission.update(Role.user(user.$id)), - Permission.delete(Role.user(user.$id)) - ] - ) + await tablesDB.createRow({ + databaseId: DATABASE_ID, + tableId: EXPENSES_TABLE_ID, + rowId: ID.unique(), + data: expenseData, + permissions: [ + Permission.read(Role.user(user.$id)), + Permission.update(Role.user(user.$id)), + Permission.delete(Role.user(user.$id)), + ], + })TablesDB is the correct service for rows post-terminology update. (appwrite.io)
🧹 Nitpick comments (64)
src/routes/blog/post/how-to-leverage-dynamic-api-keys-for-better-security/+page.markdoc (1)
84-84: Use “row in a table” for precision and consistency with Tables terminology“Row in the database” is slightly imprecise post-migration. Suggest “row in a table” to match the rest of the PR and current TablesDB wording.
-**4. Deploying and testing the function:** [Deploy your function](https://appwrite.io/docs/products/functions/functions) through the Appwrite console or the Appwrite CLI. Test the function by calling its endpoint and verifying that it performs the intended operations, such as creating a new row in the database. +**4. Deploying and testing the function:** [Deploy your function](https://appwrite.io/docs/products/functions/functions) through the Appwrite console or the Appwrite CLI. Test the function by calling its endpoint and verifying that it performs the intended operations, such as creating a new row in a table.src/routes/blog/post/product-update-jan-2025/+page.markdoc (1)
80-80: Capitalize “GitHub”.Brand capitalization.
-Plus, we resolved Github identity conflicts to ensure smooth functionality. +Plus, we resolved GitHub identity conflicts to ensure smooth functionality.src/routes/blog/post/deploy-a-pdf-generation-service-with-appwrite-functions/+page.markdoc (1)
54-56: Tighten Tables terminology and auth guidance for consistencyRecommend explicitly naming Tables/TablesDB and clarifying the auth check to reference a userId column or row.$permissions for consistency with the broader migration.
Apply this minimal copy update:
-2. Get the order row from your Appwrite database, or external data source. Unsure about this? View code recipes on the **[Appwrite Function Docs](https://appwrite.io/docs/functions).** -3. If necessary, use the order row to ensure the user has permission to see the order. For example, compare the `x-appwrite-user-id` header with the row user ID. -4. Change the function to populate the PDF template with the real order row. +2. Get the order row from Appwrite Tables (TablesDB) or your external data source. Unsure about this? See code recipes in the **[Appwrite Function Docs](https://appwrite.io/docs/functions).** +3. Authorize access using the order row—for example, compare the `x-appwrite-user-id` header with a `userId` column on the row, or enforce via `row.$permissions`. +4. Change the function to populate the PDF template with the real order row data.src/routes/blog/post/open-source-firebase-alternative/+page.markdoc (1)
133-133: Nit: Double period after “HTTPS.”Minor punctuation fix.
-- Each platform automatically provisions SSL certificates, ensuring that all content is served securely over HTTPS.. +- Each platform automatically provisions SSL certificates, ensuring that all content is served securely over HTTPS.src/routes/blog/post/product-update-december-2024/+page.markdoc (4)
35-35: Minor heading grammar tweak.Use “An” for natural phrasing.
-## MFA - Extra layer of security +## MFA - An extra layer of security
41-41: Sentence case for “integrations”.Keeps style consistent with the rest of the post.
-In May, we announced multiple AI Integrations to help developers build AI apps. With pre-built functions and an enhanced knowledge base, you can easily add features like natural language processing (NLP), image analysis, and audio processing to your projects. +In May, we announced multiple AI integrations to help developers build AI apps. With pre-built functions and an enhanced knowledge base, you can easily add features like natural language processing (NLP), image analysis, and audio processing to your projects.
49-49: Tighten CLI copy; clarify “table data” and data flow.“Between Appwrite and your CLI” is awkward; also explicitly say “data in existing tables.”
-No more overwriting or deleting existing table data during deployments. With the new Appwrite CLI, you can test functions locally and push or pull data between Appwrite and your CLI seamlessly without affecting existing data. +No more overwriting or deleting data in existing tables during deployments. With the new Appwrite CLI, you can test functions locally and seamlessly push or pull data between your local environment and Appwrite without affecting existing data.Please confirm this statement matches current CLI behavior for Tables (i.e., schema deploys don’t touch existing rows).
61-61: Role names: format consistently and verify exact labels.Use code formatting for literal role names and confirm “Billing” is the exact Console label.
-In September, we launched the much-requested [Roles](https://appwrite.io/blog/post/announcing-roles-for-enhanced-collaboration-and-security) feature, making it easy for larger teams to manage access. Alongside the "Owner" role, new options include Developer, Editor, Analyst, and Billing. +In September, we launched the much-requested [Roles](https://appwrite.io/blog/post/announcing-roles-for-enhanced-collaboration-and-security) feature, making it easy for larger teams to manage access. Alongside the `Owner` role, new options include `Developer`, `Editor`, `Analyst`, and `Billing`.src/routes/blog/post/cors-error/+page.markdoc (3)
65-66: Use Tables API terminology and broaden IDs that can trigger CORSSince Tables listRows requires databaseId/tableId, typos in any of these IDs (not just projectId) can yield 4xx responses and surface as CORS errors. Recommend clarifying.
-This one happens because of an improperly configured request, such as a typo when specifying a project ID. For example, when using the `listRows` method, -if the project ID is set incorrectly when the client is initialized, you will receive a CORS error. +This one happens because of an improperly configured request, such as a typo in your projectId, databaseId, or tableId. For example, when using the Tables API’s `listRows` method, +if any of these IDs (or the projectId used when the client is initialized) is incorrect, you will receive a CORS error.
69-69: Use standard 4xx notation instead of 40XMinor wording tweak for accuracy/consistency.
-The request returns a `40X` response, so the entire CORS check fails. +The request returns a `4xx` response, so the entire CORS check fails.
24-24: Grammar nit: pluralize “request”Small copy edit to improve readability.
-Site A, our server sitting at `myapi.com` won't allow request coming from site B, which is our client app sitting at `myfrontend.com`. +Site A, our server sitting at `myapi.com`, won't allow requests coming from site B, which is our client app sitting at `myfrontend.com`.src/routes/blog/post/open-source-vercel-alternative/+page.markdoc (3)
49-49: Grammar: remove superfluous comma after “although”.-There's no manual UI deployment support, although, there’s a CLI option. +There's no manual UI deployment support, although there’s a CLI option.
58-58: Typo: “CLi” → “CLI”.-...deploy without needing Git or the CLi. +...deploy without needing Git or the CLI.
134-134: Use product-canonical “dynamic API key” terminology
Replace the phrasing to match Appwrite’s official docs and clarify automatic injection:-Appwrite also provides a **dynamic API key automatically**, scoped and injected for both the build process and runtime (for SSR). This makes it easier to create or configure tables at build time, or securely perform server-to-server operations during SSR. +Appwrite automatically generates and injects a dynamic API key (aka ephemeral API key) for both build-time and SSR runtime. This lets you provision or configure tables during builds and securely perform server-to-server operations in SSR.src/routes/blog/post/serverless-functions-best-practices/+page.markdoc (3)
134-134: Terminology consistency: “Databases” → “Tables”To match the PR’s Tables terminology, prefer “Tables” when speaking about access control on rows.
Apply this diff:
- Appwrite Databases and Storage services can be configured to enforce access control rules. For example, you can restrict read and write access to rows by navigating to your database table settings in the Appwrite Console and setting the appropriate permissions. + Appwrite Tables and Storage services can be configured to enforce access control rules. For example, you can restrict read and write access to rows by navigating to your table settings in the Appwrite Console and setting the appropriate permissions.
138-138: Tighten phrasing on execute accessMinor clarity tweak and neutral wording re: SDKs.
Apply this diff:
- You can also configure **execute access** for your Appwrite functions, allowing you to specify who can execute the function using the client API. + You can also configure **execute access** for your Appwrite functions, allowing you to specify who can execute the function via function-level execute permissions (enforced for client SDK calls).
146-146: Grammar fixSubject–verb agreement and smoother wording.
Apply this diff:
- But in addition to that, Appwrite also use encryption for storage. + In addition, Appwrite also uses encryption for storage.src/routes/blog/post/what-is-golang/+page.markdoc (1)
12-12: Avoid time-relative phrasing; anchor to a version/date.Suggest: “Appwrite announced support for the Go SDK and Functions runtime in Appwrite 1.6.” This keeps the post evergreen.
-Appwrite has just announced support for Go SDK and Function runtime in version 1.6. +Appwrite announced support for the Go SDK and Functions runtime in Appwrite 1.6.src/routes/blog/post/improve-devex-dev-keys/+page.markdoc (1)
94-94: Prefer Promise.allSettled for a demo expected to emit 429s.Avoids a single rejection aborting the whole batch, while still logging failures.
- await Promise.all(promises); + await Promise.allSettled(promises);Rate limit on createRow is ~120 req/min for Client SDKs; many calls will reject with 429 in Step 2. (appwrite.io)
src/routes/blog/post/offline-first-journal/+page.markdoc (3)
59-64: Add a caution about permissive “Any” permissions.Good for demos, unsafe for production. Suggest a short callout that production apps should restrict to authenticated users/roles.
159-159: Use RxDB’s own nomenclature (“collections”), not “tables,” to avoid confusion.This sentence should say “create databases and collections.”
-The RxDB imports include core RxDB functionalities to create databases and tables and to add plugins, +The RxDB imports include core RxDB functionalities to create databases and collections and to add plugins,
271-275: Optional: use Mango-style sort to avoid query-builder dependency.You can do a full Mango query with sort instead of chaining. (rxdb.info)
-export const getJournals = async () => { - const db = await getDB(); - return db.entries.find().sort({ updatedAt: 'desc' }).exec(); -}; +export const getJournals = async () => { + const db = await getDB(); + return db.entries.find({ selector: {}, sort: [{ updatedAt: 'desc' }] }).exec(); +};src/routes/blog/post/hacktoberfest-ideas-2024/+page.markdoc (1)
75-75: Grammar: make product/feature phrasing consistentUse plural “Databases” and parenthetical “Tables” for clarity.
- - [Appwrite Database](https://appwrite.io/docs/products/databases) and Tables + - [Appwrite Databases](https://appwrite.io/docs/products/databases) (Tables)src/routes/blog/post/scan-receipts-with-appwrite-functions/+page.markdoc (1)
275-276: Add a short example of persisting to a tableSince this section recommends storing results in a table (event-driven), add a quick snippet showing a createRow call with the server SDK to make it actionable.
src/routes/blog/post/everything-new-with-appwrite-1.5/+page.markdoc (1)
76-76: Terminology aligns; minor wording tweak for precision on containsConsider clarifying “array element matching” to “membership testing” for array columns to better reflect semantics.
Apply this diff:
- - `contains` - partial text matches on string columns, array element matching on array columns + - `contains` - partial text matches on string columns; membership testing on array columnssrc/routes/blog/post/product-update-june/+page.markdoc (2)
29-34: Bulleted items became plain paragraphs — confirm intentSeveral lines lost the leading dash, changing list items into paragraphs. If that wasn’t intentional, restore the dashes to keep list styling.
Also applies to: 43-44, 55-56
71-71: Standardize terminology: collections → tablesElsewhere we use tables/rows/columns. Update for consistency.
Apply this diff:
- - [Fix for migration of collections, columns and indexes of Databases](https://github.com/appwrite/appwrite/issues/8044) + - [Fix for migration of tables, columns, and indexes of Databases](https://github.com/appwrite/appwrite/issues/8044)src/routes/blog/post/announcing-roles-for-enhanced-collaboration-and-security/+page.markdoc (1)
31-34: Replace relative dates with absolute dates for the promo window“Until the end of the year” and “Starting in the new year” will go stale. Use concrete dates to avoid confusion.
Apply this diff with the actual dates:
- The new feature is now available on both the Pro and Scale plans. To celebrate the new feature, until the end of the year, you can invite members with the new roles to your Pro teams for free! This is the perfect opportunity to explore the new feature and see how it enhances your team's workflow. - Starting in the new year, member seats will be priced at $15 per month as part of our standard pricing. + The new feature is now available on both the Pro and Scale plans. To celebrate the new feature, until December 31, 2024, you can invite members with the new roles to your Pro teams for free. This is the perfect opportunity to explore the new feature and see how it enhances your team's workflow. + Starting January 1, 2025, member seats will be priced at $15 per month as part of our standard pricing.src/routes/blog/post/announcing-type-generation-feature/+page.markdoc (1)
24-30: Specify minimum CLI version: Theappwrite pull tablescommand was introduced in Appwrite CLI v6.0.0. Update the snippet to require “Appwrite CLI v6.0.0+”.src/routes/blog/post/introducing-new-database-operators/+page.markdoc (2)
26-32: Use Tables client and object-style params for listRows.Recent Tables API examples use the Tables client and object params. Also align naming with tablesDB per our tutorials learning.
Based on your retrieved learnings for tutorials, consider:
-db.listRows( - '<DATABASE_ID>', - '<TABLE_ID>', - [ - Query.contains('content', ['happy', 'love']), - ] - ) +tablesDB.listRows({ + databaseId: '<DATABASE_ID>', + tableId: '<TABLE_ID>', + queries: [ + Query.contains('content', ['happy', 'love']), + ], +})Note: If this blog intentionally uses positional args, please confirm the SDK version this targets.
35-35: Clarify array-column phrasing."set a string column to act as an array" can confuse readers. Prefer "create a string[] column (array=true)".
-It’s important to note that the contains operator also works on array columns as well. For example, if we set a string column to act as an array, you could search this array in the same way you would search any other string. +It’s important to note that the contains operator also works on array columns. For example, if you define a string[] column (array=true), you can search this array the same way as strings.src/routes/blog/post/manage-user-permissions-with-labels-and-teams/+page.markdoc (1)
81-81: Capitalize brand and Console.Minor polish.
-That's it for creating a Team and adding members from the appwrite console. +That's it for creating a Team and adding members from the Appwrite Console.src/routes/blog/post/announcing-go-support/+page.markdoc (2)
191-216: Storage example compiles, but keep imports tidy.No issues; consider grouping imports, but optional.
219-219: Grammar nit."the ones the return" → "the ones that return".
-Some of our API endpoints such as the ones that return preferences from the Accounts and Teams APIs as well as the ones the return rows from the Appwrite Database are loosely typed... +Some of our API endpoints—such as those that return preferences from the Accounts and Teams APIs, as well as those that return rows from the Appwrite Database—are loosely typed...src/routes/blog/post/simplify-your-data-management-with-relationships/+page.markdoc (1)
50-51: Grammar: “a column” (not “an column”)-...the reviews table will not have an column containing the related movie. +...the reviews table will not have a column containing the related movie.src/routes/blog/post/how-to-execute-database-migration-with-appwrite-cli/+page.markdoc (2)
61-63: Stale terminology (“collections”)This section still references “collections”; the rest of the post uses “tables”.
-To make changes to your collections, edit the `appwrite.config.json` file. +To make changes to your tables, edit the `appwrite.config.json` file.
95-104: Avoid storing phone numbers as integersPhone numbers aren’t numeric (leading zeros, formatting, country codes). Prefer string.
{ "key": "phone", - "type": "integer", + "type": "string", "status": "available", "error": "", "required": false, "array": false, - "min": 1, - "max": 100, + "min": 1, + "max": 32, "default": null}src/routes/blog/post/announcing-csv-imports/+page.markdoc (1)
25-25: Wording: avoid repetition (“row represents a row”)-- Each subsequent row represents a row, with values separated by commas +- Each subsequent line represents a data row, with values separated by commassrc/routes/blog/post/how-to-optimize-your-appwrite-project/+page.markdoc (2)
4-4: Typo in description (“yout” → “your”)-description: Learn how to optimize your Appwrite project, manage resource usage, costs, and ensure smooth performance as yout application scales. +description: Learn how to optimize your Appwrite project, manage resource usage, costs, and ensure smooth performance as your application scales.
249-249: Broken link schemeMissing slashes in URL.
-- [Serverless functions 101: Best practices](http:appwrite.io/blog/post/serverless-functions-best-practices) +- [Serverless functions 101: Best practices](https://appwrite.io/blog/post/serverless-functions-best-practices)src/routes/blog/post/announcing-auto-increment-support/+page.markdoc (1)
40-40: Use “column” consistently (not “field”).Terminology in this PR adopts “columns.” Align this sentence.
-For numeric ordering based on insertion order, you can use the `$sequence` field, which Appwrite automatically adds to all rows. This field increments with each new insert. +For numeric ordering based on insertion order, you can use the `$sequence` column, which Appwrite automatically adds to all rows. This column increments with each new insert.src/routes/blog/post/introducing-new-appwrite-cli/+page.markdoc (4)
12-12: Pluralize “table” → “tables.”Reads better and matches service naming elsewhere.
-...apply changes to your Appwrite table. +...apply changes to your Appwrite tables.
92-92: Use the correct service name in the command.Standardize on
appwrite push tables.-When running `appwrite push table`, the CLI will compare... +When running `appwrite push tables`, the CLI will compare...
108-113: Tighten grammar and code punctuation.Move comma outside backticks and fix “read” → “recreated.”
-In this example, we can see that because we've renamed the column `times` to `time,` it will get deleted and read. We must also recreate the `timezone` column because we've changed its size from 256 to 255. +In this example, because we've renamed the column `times` to `time`, it will be deleted and recreated. We must also recreate the `timezone` column because we've changed its size from 256 to 255.
120-121: Keep punctuation outside inline code.Remove trailing comma and period from inside backticks.
-...such as `appwrite push tables,` to pre-answer all of them with `YES.` +...such as `appwrite push tables`, to pre-answer all of them with `YES`.src/routes/blog/post/introducing-functions-ecosystem/+page.markdoc (2)
67-76: “scheduledAt” is a parameter, not a column.Adjust the comment to avoid DB terminology here.
- invoiceDate.toISOString() // New scheduledAt column + invoiceDate.toISOString() // New scheduledAt parameter
119-121: Use “fields” instead of “columns” for Functions metadata.Columns are DB-specific; executions/deployments have fields/attributes.
-You can now filter Function executions and deployments based on various columns, making it easier to monitor and debug your Functions: +You can now filter Function executions and deployments based on various fields, making it easier to monitor and debug your Functions:src/routes/blog/post/3-things-you-can-build-with-go-runtime/+page.markdoc (3)
202-204: Use “tableId” consistently instead of “collId” for clarity.You’ve migrated to Tables/Rows, but variable names still say “collId”. Rename for consistency/readability.
-func DoesTableExist(dbs tablesdb.TablesDB, dbId string, collId string) bool { - _, err := dbs.GetTable(dbId, collId) +func DoesTableExist(dbs tablesdb.TablesDB, dbId string, tableId string) bool { + _, err := dbs.GetTable(dbId, tableId) @@ -func DoesColumnExist(dbs tablesdb.TablesDB, dbId string, collId string, attribId string) bool { - _, err := dbs.GetColumn(dbId, collId, attribId) +func DoesColumnExist(dbs tablesdb.TablesDB, dbId string, tableId string, attribId string) bool { + _, err := dbs.GetColumn(dbId, tableId, attribId) @@ -func InitialiseDatabase(Context openruntimes.Context, dbs tablesdb.TablesDB, dbId string, collId string) { +func InitialiseDatabase(Context openruntimes.Context, dbs tablesdb.TablesDB, dbId string, tableId string) { @@ - doesCollExist := DoesTableExist(dbs, dbId, collId) + doesCollExist := DoesTableExist(dbs, dbId, tableId) @@ - dbs.CreateTable( - dbId, - collId, + dbs.CreateTable( + dbId, + tableId, @@ - doesAttribExist := DoesColumnExist(dbs, dbId, collId, "longUrl") + doesAttribExist := DoesColumnExist(dbs, dbId, tableId, "longUrl") @@ - dbs.CreateUrlColumn( - dbId, - collId, + dbs.CreateUrlColumn( + dbId, + tableId, @@ -collId := "urlTable" -services.InitialiseDatabase(Context, *tablesDB, dbId, collId) +tableId := "urlTable" +services.InitialiseDatabase(Context, *tablesDB, dbId, tableId) @@ -row, err := tablesDB.GetRow(dbId, collId, shortId) +row, err := tablesDB.GetRow(dbId, tableId, shortId)Also applies to: 227-234, 237-246, 283-286, 329-338
218-248: Prefer passing a pointer to TablesDB to avoid copying and make the intent explicit.Service methods likely have pointer receivers; passing by pointer avoids unnecessary copies and is idiomatic.
-func InitialiseDatabase(Context openruntimes.Context, dbs tablesdb.TablesDB, dbId string, tableId string) { +func InitialiseDatabase(Context openruntimes.Context, dbs *tablesdb.TablesDB, dbId string, tableId string) { @@ -services.InitialiseDatabase(Context, *tablesDB, dbId, tableId) +services.InitialiseDatabase(Context, tablesDB, dbId, tableId)Also applies to: 279-286
348-349: Tighten the scope list and fix punctuation.Remove trailing comma; also verify whether both
databases.*and{tables,columns,rows}.*are all required for this example.-... `databases.read`, `databases.write`, `tables.read`, `tables.write`, `columns.read`, `columns.write`, `rows.read`, `rows.write`, +... `databases.read`, `databases.write`, `tables.read`, `tables.write`, `columns.read`, `columns.write`, `rows.read`, `rows.write`.Would you confirm the minimal scopes needed (especially if creating DB/table/column at runtime)?
src/routes/blog/post/announcing-atomic-numeric-operations/+page.markdoc (1)
89-96: Concurrency phrasing check.“The row is locked during the update” — confirm this reflects the actual implementation (atomic server-side write vs. explicit row lock). Adjust wording if needed.
src/routes/blog/post/appwrite-realtime-for-flutter/+page.markdoc (2)
236-239: Subscribe to a scoped rows channel to reduce noise.
'rows'listens to all rows across all DBs/tables. Scope to your DB/table for fewer events and better perf.- subscription = realtime.subscribe([ - 'rows' // subscribe to all rows in every database and table - ]); + subscription = realtime.subscribe([ + 'databases.${database}.tables.${itemsTable}.rows' // only this table's rows + ]);Please confirm the exact channel pattern for rows in the latest Flutter SDK docs.
Also applies to: 362-364
199-205: Minor terminology tweak (optional).“Appwrite database service” → “Appwrite Tables service” to match TablesDB.
src/routes/blog/post/encrypted-attributes-for-sensitive-fields/+page.markdoc (3)
3-5: Align title/description terminology (“columns” vs “attributes”).Description still mentions “encrypted string attributes.” Update to “columns” for consistency with the title/body.
title: Secure sensitive database fields with encrypted string columns -description: Learn how to use encrypted string attributes to protect sensitive data in your Appwrite database. +description: Learn how to use encrypted string columns to protect sensitive data in your Appwrite database.
85-85: Grammar: “an column” → “a column”.Quick copyedit.
-Once an column is marked as encrypted, that decision cannot be reversed. +Once a column is marked as encrypted, that decision cannot be reversed.
94-94: Punctuation: add period.Minor polish.
-If you are unsure, it is better to begin with unencrypted fields and migrate later once your needs are clearer +If you are unsure, it is better to begin with unencrypted fields and migrate later once your needs are clearer.src/routes/blog/post/track-document-order-with-sequence/+page.markdoc (1)
157-157: Wording: “id columns” → “id attributes”.These are HTML attributes.
-This form captures the ticket title and description. Note the `id` columns on the form and inputs. +This form captures the ticket title and description. Note the `id` attributes on the form and inputs.src/routes/blog/post/ai-crystal-ball/+page.markdoc (1)
509-509: Remove stray**in export.Typo will break the code snippet.
-export const db = {** +export const db = {src/routes/blog/post/building-init-giveaway-app/+page.markdoc (1)
345-349: Optionally narrow Realtime to create events only.Avoid reacting to updates/deletes by scoping to creation events.
- return client.subscribe( - `databases.${DATABASE_NAME}.tables.${TABLE_NAME}.rows`, + return client.subscribe( + `databases.${DATABASE_NAME}.tables.${TABLE_NAME}.rows.*.create`, (response) => { // ... } );src/routes/blog/post/build-personal-crm-sveltekit/+page.markdoc (1)
165-167: Remove unused imports.ID and Query are not used in +server.js after the refactor.
-import { ID, Query } from 'node-appwrite'; +// import { Query } from 'node-appwrite';src/routes/blog/post/best-pagination-technique/+page.markdoc (1)
48-51: Typo: add spacing around the “sum” column.Minor readability fix.
-`sum`column +`sum` columnsrc/routes/blog/post/build-fullstack-svelte-appwrite/+page.markdoc (3)
75-77: Permissions and Row Security guidance: grammar + clarity nits.
- Line 92: lowercase “Open” → “open”.
- All good on enabling Row Security and table-level Create for Users; keep the screenshot step.
Apply:
- To ensure that users can only access their own expenses, Open the table's **Settings** tab ... + To ensure that users can only access their own expenses, open the table's **Settings** tab ...Also applies to: 90-96
156-156: “column” → “attribute”It’s an HTML attribute, not a column.
- The `data-sveltekit-preload-data="hover"` column enables ... + The `data-sveltekit-preload-data="hover"` attribute enables ...
281-283: Unused import (optional).ID isn’t used in +page.svelte; import lives in the store. Safe to remove.
- import { ID } from 'appwrite'
src/routes/blog/post/3-things-you-can-build-with-go-runtime/+page.markdoc
Outdated
Show resolved
Hide resolved
src/routes/blog/post/build-fullstack-svelte-appwrite/+page.markdoc
Outdated
Show resolved
Hide resolved
src/routes/blog/post/build-fullstack-svelte-appwrite/+page.markdoc
Outdated
Show resolved
Hide resolved
src/routes/blog/post/build-fullstack-svelte-appwrite/+page.markdoc
Outdated
Show resolved
Hide resolved
…kdoc Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
…kdoc Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
…kdoc Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (2)
src/routes/blog/post/understand-data-queries/+page.markdoc (2)
86-93: Use object-arg listRows and pass queries as an array.Current call uses positional args and a single Query expression; TablesDB expects queries as an array, and examples should prefer the object-argument form. [Duplicate of earlier feedback, still present here.]
Apply:
-const movieData1 = tablesDB.listRows( - '[DATABASE_ID]', - '[TABLE_ID]', - Query.or([ - Query.equal('title', ['Back To The Future', 'Top Gun']), - Query.greaterThan('year', 2017) - ]) -); +const movieData1 = await tablesDB.listRows({ + databaseId: '[DATABASE_ID]', + tableId: '[TABLE_ID]', + queries: [ + Query.or([ + Query.equal('title', ['Back To The Future', 'Top Gun']), + Query.greaterThan('year', 2017), + ]), + ], +});Queries are passed via the queries array, and logical operators nest sub-queries. (appwrite.io)
96-103: Same fix for AND example: object-arg + queries array.Maintain parity with the OR example and SDK conventions. [Duplicate of earlier feedback.]
-const movieData2 = tablesDB.listRows( - '[DATABASE_ID]', - '[TABLE_ID]', - Query.and([ - Query.startsWith("title", "Once"), - Query.greaterThan('year', 1995) - ]) -); +const movieData2 = await tablesDB.listRows({ + databaseId: '[DATABASE_ID]', + tableId: '[TABLE_ID]', + queries: [ + Query.and([ + Query.startsWith('title', 'Once'), + Query.greaterThan('year', 1995), + ]), + ], +});AND/OR group nested sub-queries, and queries must be an array passed to list endpoints. (appwrite.io)
🧹 Nitpick comments (2)
src/routes/blog/post/understand-data-queries/+page.markdoc (2)
70-70: Nit: Prefer method-style naming.Consider “listRows API” (camelCase) instead of “list rows API” for consistency with the SDK.
106-110: LGTM; aligns with object-arg form.Optional: add await for consistency with the other examples.
-const movieData3 = tablesDB.listRows({ +const movieData3 = await tablesDB.listRows({ databaseId: '[DATABASE_ID]', tableId: '[TABLE_ID]', queries: [Query.contains('director', ['Christopher Nolan'])], });
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
src/routes/blog/post/build-fullstack-svelte-appwrite/+page.markdoc(8 hunks)src/routes/blog/post/understand-data-queries/+page.markdoc(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- src/routes/blog/post/build-fullstack-svelte-appwrite/+page.markdoc
🧰 Additional context used
🧠 Learnings (2)
📓 Common learnings
Learnt from: ebenezerdon
PR: appwrite/website#2372
File: src/routes/docs/tutorials/nuxt/step-6/+page.markdoc:79-83
Timestamp: 2025-09-05T19:35:04.162Z
Learning: In Nuxt tutorial files, the correct Appwrite database instance to use is `tablesDB` (imported from "~/appwrite"), not `database`. All tablesDB method calls should use the object parameter format: listRows({ databaseId, tableId, queries }), createRow({ databaseId, tableId, rowId, data }), and deleteRow({ databaseId, tableId, rowId }).
Learnt from: ebenezerdon
PR: appwrite/website#2372
File: src/routes/docs/tutorials/react/step-6/+page.markdoc:70-75
Timestamp: 2025-09-05T19:35:53.943Z
Learning: In React tutorial files, the correct Appwrite database instance to import is `tablesDB` from "../appwrite", not `databases`. The import statement should be `import { tablesDB } from "../appwrite"` to match the usage throughout the React tutorial code.
Learnt from: ebenezerdon
PR: appwrite/website#2372
File: src/routes/docs/tutorials/react-native/step-6/+page.markdoc:67-73
Timestamp: 2025-09-05T19:35:59.449Z
Learning: In React Native tutorials, the lib/appwrite.js file exports `tablesDB` (not `databases`), so imports should use `import { tablesDB } from "../lib/appwrite"` to match the export pattern established in step-3.
Learnt from: ebenezerdon
PR: appwrite/website#2372
File: src/routes/docs/tutorials/react-native/step-6/+page.markdoc:67-73
Timestamp: 2025-09-05T19:35:59.449Z
Learning: In React Native tutorials, the lib/appwrite.js file exports `tablesDB` (not `databases`), so imports should use `import { tablesDB } from "../lib/appwrite"` to match the export pattern established in step-3.
📚 Learning: 2025-09-05T19:35:04.162Z
Learnt from: ebenezerdon
PR: appwrite/website#2372
File: src/routes/docs/tutorials/nuxt/step-6/+page.markdoc:79-83
Timestamp: 2025-09-05T19:35:04.162Z
Learning: In Nuxt tutorial files, the correct Appwrite database instance to use is `tablesDB` (imported from "~/appwrite"), not `database`. All tablesDB method calls should use the object parameter format: listRows({ databaseId, tableId, queries }), createRow({ databaseId, tableId, rowId, data }), and deleteRow({ databaseId, tableId, rowId }).
Applied to files:
src/routes/blog/post/understand-data-queries/+page.markdoc
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
- GitHub Check: build
- GitHub Check: tests
🔇 Additional comments (1)
src/routes/blog/post/understand-data-queries/+page.markdoc (1)
77-84: Import and instantiation look good.TablesDB usage aligns with the new API surface.
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
src/routes/blog/post/how-to-optimize-your-appwrite-project/+page.markdoc (2)
56-64: Use object-argument form for listRows.The second pagination example also uses positional arguments instead of the object-argument form.
Based on learnings
Apply this diff:
-const secondPage = await tablesDB.listRows( - '<DATABASE_ID>', - '<TABLE_ID>', - [ - Query.equal('author', 'Meredith Palmer'), - Query.limit(20), - Query.offset(20), // Fetch the next 20 records - ] -}) +const secondPage = await tablesDB.listRows({ + databaseId: '<DATABASE_ID>', + tableId: '<TABLE_ID>', + queries: [ + Query.equal('author', ['Meredith Palmer']), + Query.limit(20), + Query.offset(20), // Fetch the next 20 records + ] +});
253-253: Update outdated terminology in FAQ.The FAQ section still references
listDocuments()instead oflistRows(), which is inconsistent with the terminology migration in this PR.Apply this diff:
-Use smart querying with `listDocuments()` and filters instead of multiple requests. Combine queries, enable pagination, and use the Realtime API for live updates instead of polling. This reduces server load and speeds up responses. +Use smart querying with `listRows()` and filters instead of multiple requests. Combine queries, enable pagination, and use the Realtime API for live updates instead of polling. This reduces server load and speeds up responses.
♻️ Duplicate comments (5)
src/routes/blog/post/improve-devex-dev-keys/+page.markdoc (3)
30-30: Version requirement and CORS setup need updates (see previous comments).The existing review comment correctly identifies that TablesDB requires Appwrite 1.8+ and that a Web platform configuration step should be added to avoid CORS errors.
84-89: createRow should use object-parameter syntax (see previous comment).The existing review comment correctly identifies that the positional argument syntax is deprecated. Based on learnings from tutorial files, the correct pattern is
createRow({ databaseId, tableId, rowId, data }).
98-98: Terminology updated, but error explanation needs clarification (see previous comment).The "rows" terminology is correct. However, the existing review comment correctly identifies that the explanation should distinguish between CORS errors (when no Web platform is configured) and 429 rate limit errors.
src/routes/blog/post/how-to-optimize-your-appwrite-project/+page.markdoc (2)
30-34: Use object-argument form for listRows consistency.This code example uses positional arguments, which is inconsistent with the SDK usage pattern. Based on learnings, tablesDB methods should use object parameter format.
This issue was already flagged in a previous review comment.
46-54: Use object-argument form for listRows.The pagination example uses positional arguments, which is inconsistent with the SDK usage pattern established elsewhere in the codebase.
Based on learnings
Apply this diff to use the object-argument form:
-const firstPage = await tablesDB.listRows( - '<DATABASE_ID>', - '<TABLE_ID>', - [ - Query.equal('author', 'Meredith Palmer'), - Query.limit(20), - Query.offset(0),// Fetch the first 20 records - ] -}) +const firstPage = await tablesDB.listRows({ + databaseId: '<DATABASE_ID>', + tableId: '<TABLE_ID>', + queries: [ + Query.equal('author', ['Meredith Palmer']), + Query.limit(20), + Query.offset(0), // Fetch the first 20 records + ] +});
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (9)
src/routes/blog/post/appwrite-realtime-for-flutter/+page.markdoc(12 hunks)src/routes/blog/post/build-personal-crm-sveltekit/+page.markdoc(5 hunks)src/routes/blog/post/ci-cd-examples-in-appwrite/+page.markdoc(5 hunks)src/routes/blog/post/how-to-build-a-remote-tech-stack/+page.markdoc(6 hunks)src/routes/blog/post/how-to-optimize-your-appwrite-project/+page.markdoc(4 hunks)src/routes/blog/post/improve-devex-dev-keys/+page.markdoc(5 hunks)src/routes/blog/post/open-source-firebase-alternative/+page.markdoc(1 hunks)src/routes/blog/post/open-source-vercel-alternative/+page.markdoc(2 hunks)src/routes/blog/post/serverless-functions-best-practices/+page.markdoc(2 hunks)
🚧 Files skipped from review as they are similar to previous changes (4)
- src/routes/blog/post/ci-cd-examples-in-appwrite/+page.markdoc
- src/routes/blog/post/open-source-vercel-alternative/+page.markdoc
- src/routes/blog/post/open-source-firebase-alternative/+page.markdoc
- src/routes/blog/post/how-to-build-a-remote-tech-stack/+page.markdoc
🧰 Additional context used
🧠 Learnings (7)
📓 Common learnings
Learnt from: ebenezerdon
Repo: appwrite/website PR: 2372
File: src/routes/docs/tutorials/react/step-6/+page.markdoc:70-75
Timestamp: 2025-09-05T19:35:53.943Z
Learning: In React tutorial files, the correct Appwrite database instance to import is `tablesDB` from "../appwrite", not `databases`. The import statement should be `import { tablesDB } from "../appwrite"` to match the usage throughout the React tutorial code.
Learnt from: ebenezerdon
Repo: appwrite/website PR: 2372
File: src/routes/docs/tutorials/react-native/step-6/+page.markdoc:67-73
Timestamp: 2025-09-05T19:35:59.449Z
Learning: In React Native tutorials, the lib/appwrite.js file exports `tablesDB` (not `databases`), so imports should use `import { tablesDB } from "../lib/appwrite"` to match the export pattern established in step-3.
Learnt from: ebenezerdon
Repo: appwrite/website PR: 2372
File: src/routes/docs/tutorials/react-native/step-6/+page.markdoc:67-73
Timestamp: 2025-09-05T19:35:59.449Z
Learning: In React Native tutorials, the lib/appwrite.js file exports `tablesDB` (not `databases`), so imports should use `import { tablesDB } from "../lib/appwrite"` to match the export pattern established in step-3.
Learnt from: ebenezerdon
Repo: appwrite/website PR: 2372
File: src/routes/docs/tutorials/nuxt/step-6/+page.markdoc:79-83
Timestamp: 2025-09-05T19:35:04.162Z
Learning: In Nuxt tutorial files, the correct Appwrite database instance to use is `tablesDB` (imported from "~/appwrite"), not `database`. All tablesDB method calls should use the object parameter format: listRows({ databaseId, tableId, queries }), createRow({ databaseId, tableId, rowId, data }), and deleteRow({ databaseId, tableId, rowId }).
📚 Learning: 2025-09-05T19:35:04.162Z
Learnt from: ebenezerdon
Repo: appwrite/website PR: 2372
File: src/routes/docs/tutorials/nuxt/step-6/+page.markdoc:79-83
Timestamp: 2025-09-05T19:35:04.162Z
Learning: In Nuxt tutorial files, the correct Appwrite database instance to use is `tablesDB` (imported from "~/appwrite"), not `database`. All tablesDB method calls should use the object parameter format: listRows({ databaseId, tableId, queries }), createRow({ databaseId, tableId, rowId, data }), and deleteRow({ databaseId, tableId, rowId }).
Applied to files:
src/routes/blog/post/improve-devex-dev-keys/+page.markdocsrc/routes/blog/post/how-to-optimize-your-appwrite-project/+page.markdocsrc/routes/blog/post/build-personal-crm-sveltekit/+page.markdocsrc/routes/blog/post/appwrite-realtime-for-flutter/+page.markdoc
📚 Learning: 2025-09-05T19:35:53.943Z
Learnt from: ebenezerdon
Repo: appwrite/website PR: 2372
File: src/routes/docs/tutorials/react/step-6/+page.markdoc:70-75
Timestamp: 2025-09-05T19:35:53.943Z
Learning: In React tutorial files, the correct Appwrite database instance to import is `tablesDB` from "../appwrite", not `databases`. The import statement should be `import { tablesDB } from "../appwrite"` to match the usage throughout the React tutorial code.
Applied to files:
src/routes/blog/post/improve-devex-dev-keys/+page.markdocsrc/routes/blog/post/how-to-optimize-your-appwrite-project/+page.markdocsrc/routes/blog/post/build-personal-crm-sveltekit/+page.markdocsrc/routes/blog/post/appwrite-realtime-for-flutter/+page.markdoc
📚 Learning: 2025-09-05T19:35:59.449Z
Learnt from: ebenezerdon
Repo: appwrite/website PR: 2372
File: src/routes/docs/tutorials/react-native/step-6/+page.markdoc:67-73
Timestamp: 2025-09-05T19:35:59.449Z
Learning: In React Native tutorials, the lib/appwrite.js file exports `tablesDB` (not `databases`), so imports should use `import { tablesDB } from "../lib/appwrite"` to match the export pattern established in step-3.
Applied to files:
src/routes/blog/post/improve-devex-dev-keys/+page.markdocsrc/routes/blog/post/how-to-optimize-your-appwrite-project/+page.markdocsrc/routes/blog/post/build-personal-crm-sveltekit/+page.markdocsrc/routes/blog/post/appwrite-realtime-for-flutter/+page.markdoc
📚 Learning: 2025-10-24T22:17:14.669Z
Learnt from: stnguyen90
Repo: appwrite/website PR: 2520
File: src/routes/docs/advanced/self-hosting/production/updates/+page.markdoc:13-15
Timestamp: 2025-10-24T22:17:14.669Z
Learning: In Appwrite versioning, RC (Release Candidate) versions like `1.6.2-RC1` come before the stable release `1.6.2`. Documentation should recommend upgrading to stable versions, not RC versions.
Applied to files:
src/routes/blog/post/improve-devex-dev-keys/+page.markdoc
📚 Learning: 2025-09-25T05:26:19.287Z
Learnt from: BretRen
Repo: appwrite/website PR: 2442
File: src/routes/docs/products/auth/email-password/+page.markdoc:22-31
Timestamp: 2025-09-25T05:26:19.287Z
Learning: Appwrite JavaScript SDKs now support object-based arguments instead of positional arguments as of 2025. The account.create method should be called with an object parameter containing userId, email, password, and optional name, rather than positional arguments. Positional arguments still work but are deprecated.
Applied to files:
src/routes/blog/post/improve-devex-dev-keys/+page.markdoc
📚 Learning: 2025-09-25T05:24:12.551Z
Learnt from: BretRen
Repo: appwrite/website PR: 2442
File: src/routes/docs/products/auth/email-password/+page.markdoc:50-56
Timestamp: 2025-09-25T05:24:12.551Z
Learning: Appwrite v17+ uses object parameters consistently across Account methods. Both account.create({ userId, email, password }) and account.createEmailPasswordSession({ email, password }) use object parameters instead of positional arguments.
Applied to files:
src/routes/blog/post/improve-devex-dev-keys/+page.markdoc
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
- GitHub Check: assets
- GitHub Check: build
- GitHub Check: tests
🔇 Additional comments (16)
src/routes/blog/post/improve-devex-dev-keys/+page.markdoc (5)
26-26: LGTM! Terminology correctly updated.The migration from "document" to "row" is consistent with the TablesDB API changes.
32-36: LGTM! Table setup and terminology correctly migrated.The column definition and permissions setup now correctly reference "table" instead of "collection", consistent with TablesDB.
60-61: LGTM! User-facing text correctly updated.Button label and description now correctly use "rows" terminology, matching the TablesDB API migration.
79-79: LGTM! TablesDB instantiation is correct.The migration from
Appwrite.DatabasestoAppwrite.TablesDBwith thetablesDBvariable name follows the correct pattern.
117-117: LGTM! Button reference correctly updated.The button text reference now correctly uses "rows" terminology, consistent with the TablesDB migration throughout the document.
src/routes/blog/post/serverless-functions-best-practices/+page.markdoc (4)
98-98: LGTM!The text clarification improves readability and clearly explains the impact of cold starts on user experience.
102-104: Excellent additions to performance guidance!The new content about warm-up strategies and resource reuse provides valuable optimization techniques while appropriately warning readers about potential trade-offs (costs, abuse, stale data). This balanced guidance will help readers make informed decisions.
140-142: Great addition to the authorization section!This new content about configuring execute access provides valuable security guidance that complements the existing authorization information. It helps readers understand how to control function execution at the API level.
136-136: No terminology update needed for "Appwrite Databases".The phrase "Appwrite Databases and Storage services" correctly uses the product service names. The terminology updates in line 136 are accurate:
- "documents" → "rows" ✓
- "collection" → "table" ✓
- "Appwrite Databases" (service name) remains correct ✓
"Appwrite Databases" refers to the service/product name, while "TablesDB" is the new UI/API interface. The data structure terminology has been properly updated (rows, tables, columns), and the service reference is appropriately distinct. No changes are required.
src/routes/blog/post/build-personal-crm-sveltekit/+page.markdoc (2)
85-93: LGTM! Correct TablesDB import and instantiation.The migration from Databases to TablesDB is correctly implemented with proper imports and client instantiation.
164-214: LGTM! API route correctly uses wrapper functions.The API route implementation properly uses the exported database wrapper functions and correctly accesses the
rowsproperty from responses, aligning with the TablesDB migration.src/routes/blog/post/appwrite-realtime-for-flutter/+page.markdoc (5)
31-48: LGTM! UI terminology properly updated.The setup instructions correctly use the new terminology: "Create table", "Columns tab", "Table ID", and "Column Key". All references are consistent with the TablesDB model.
203-230: LGTM! TablesDB initialization and API usage are correct.The code properly migrates to the new Tables API:
- Uses
TablesDBclass- Calls
listRows()with correct named parameters- References
res.rowsinstead ofres.documentsAll syntax is appropriate for Flutter/Dart.
264-294: LGTM! CRUD operations properly migrated.The code correctly uses:
createRow()withtableIdandrowIdparametersdeleteRow()withtableIdandrowIdparametersAll method signatures and parameter names align with the new Tables API.
298-463: LGTM! Complete example is consistent and correct.The full example properly demonstrates the TablesDB migration:
- Consistent use of
TablesDB,itemsTablevariable naming- All CRUD operations (
listRows,createRow,deleteRow) use correct method names and parameters- Response handling uses
res.rowscorrectly- The code provides a complete, working reference for readers
235-259: Code is correct; consider adding context about production channel patterns.The
'rows'channel syntax is confirmed correct. The genericrowschannel subscribes to all rows across all databases and tables, and your code comment accurately reflects this behavior.For a tutorial, this broad subscription is appropriate for simplicity. However, consider adding a note that production applications would typically use specific channels like
databases.<DATABASE_ID>.tables.<TABLE_ID>.rowsfor efficiency and to receive only relevant events.
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (4)
src/routes/blog/post/building-init-giveaway-app/+page.markdoc (1)
126-126: Fix the OAuthProvider import.The
OAuthProvideris not exported from./appwrite(see line 105), causing this import to fail. Import it directly from the Appwrite SDK instead.Apply this diff:
-import { account, OAuthProvider } from './appwrite'; +import { account } from './appwrite'; +import { OAuthProvider } from 'appwrite';src/routes/blog/post/build-personal-crm-sveltekit/+page.markdoc (3)
27-35: Fixnotescolumn type (and optionallyphone).The schema table defines
notesasIntegerwith size 2000, but the app treatsnotesas free‑text (textarea). This will reject string input at write time. Please changenotesto a string/text column (e.g.,String | 2000). Optionally, consider storingphoneasStringas well if you need+,-, or leading zeros.Example:
-| notes | Integer | 2000 | No | +| notes | String | 2000 | No |
176-188: Fix API route path vs. fetch URL mismatch (/api/contactvs/api/contacts).The tutorial creates
src/routes/api/contact/+server.js, which maps to/api/contact, but all frontend calls use/api/contacts. As written, every fetch will hit a 404.Align these by either renaming the route folder to
contactsor updating the fetch URLs. Minimal change is to keep the route ascontactand change the client:-const response = await fetch('/api/contacts'); +const response = await fetch('/api/contact'); ... -const response = await fetch('/api/contacts', { +const response = await fetch('/api/contact', { ... -const response = await fetch('/api/contacts', { +const response = await fetch('/api/contact', { ... -const response = await fetch('/api/contacts', { +const response = await fetch('/api/contact', {Also applies to: 262-268, 320-327, 355-362, 387-393
588-590: Update FAQ wording fromupsertDocuments()toupsertRows().The FAQ still mentions
upsertDocuments(), but the article code and current Appwrite Tables bulk API useupsertRows(). This change ensures consistency throughout the article and aligns with the modern TablesDB API.-Instead of looping over every record, use batch APIs (like Appwrite's upsertDocuments()). +Instead of looping over every record, use batch APIs (like Appwrite's upsertRows()).
🧹 Nitpick comments (8)
src/routes/blog/post/track-document-order-with-sequence/+page.markdoc (3)
36-36: Simplify the heading to "Add columns".The phrase "Add row columns" is redundant. In database terminology, columns define the schema of a table, so "Add columns" is clearer and more concise.
Apply this diff:
-## Add row columns +## Add columns
157-157: Use "attributes" instead of "columns" for HTML elements.In a database-focused tutorial, referring to HTML
idattributes as "columns" may confuse readers. Use "attributes" to distinguish HTML element properties from database columns.Apply this diff:
-This form captures the ticket title and description. Note the `id` columns on the form and inputs. We'll use these in our JavaScript. +This form captures the ticket title and description. Note the `id` attributes on the form and inputs. We'll use these in our JavaScript.
264-264: Update comment to match the actual code.The comment states the code "uses
'unique()'" but the actual code at line 248 usesAppwrite.ID.unique(), which is the correct SDK method. Update the comment for accuracy.Apply this diff:
-This code creates a new row in your table when the form is submitted. It uses `'unique()'` to generate a unique ID. After submission, the form is reset and the list of tickets is reloaded to show the new entry. +This code creates a new row in your table when the form is submitted. It uses `Appwrite.ID.unique()` to generate a unique ID. After submission, the form is reset and the list of tickets is reloaded to show the new entry.src/routes/blog/post/3-things-you-can-build-with-go-runtime/+page.markdoc (3)
202-202: Update parameter names for consistency with new terminology.The parameter names
collIdandattribIdshould be updated totableIdandcolumnIdrespectively to align with the new table/column terminology.-func DoesTableExist(dbs tablesdb.TablesDB, dbId string, collId string) bool { - _, err := dbs.GetTable(dbId, collId) +func DoesTableExist(dbs tablesdb.TablesDB, dbId string, tableId string) bool { + _, err := dbs.GetTable(dbId, tableId) if err != nil { return false } return true } -func DoesColumnExist(dbs tablesdb.TablesDB, dbId string, collId string, attribId string) bool { - _, err := dbs.GetColumn(dbId, collId, attribId) +func DoesColumnExist(dbs tablesdb.TablesDB, dbId string, tableId string, columnId string) bool { + _, err := dbs.GetColumn(dbId, tableId, columnId) if err != nil { return false } return true } -func InitialiseDatabase(Context openruntimes.Context, dbs tablesdb.TablesDB, dbId string, collId string) { +func InitialiseDatabase(Context openruntimes.Context, dbs tablesdb.TablesDB, dbId string, tableId string) { doesDbExist := DoesDatabaseExist(dbs, dbId) if !doesDbExist { dbs.Create( dbId, "URL Databases", ) } - doesCollExist := DoesTableExist(dbs, dbId, collId) + doesTableExist := DoesTableExist(dbs, dbId, tableId) - if !doesCollExist { + if !doesTableExist { dbs.CreateTable( dbId, - collId, + tableId, "URLs", dbs.WithCreateTablePermissions([]string{permission.Read("any")}), ) } - doesAttribExist := DoesColumnExist(dbs, dbId, collId, "longUrl") + doesColumnExist := DoesColumnExist(dbs, dbId, tableId, "longUrl") - if !doesAttribExist { + if !doesColumnExist { dbs.CreateUrlColumn( dbId, - collId, + tableId, "longUrl", true, dbs.WithCreateUrlColumnArray(false), ) } }Also applies to: 210-210, 218-218
282-282: Update variable name for consistency with new terminology.The variable
collIdshould be renamed totableIdto align with the table-centric terminology introduced in this PR.dbId := "urlDatabase" - collId := "urlTable" + tableId := "urlTable" - services.InitialiseDatabase(Context, *tablesDB, dbId, collId) + services.InitialiseDatabase(Context, *tablesDB, dbId, tableId)Note: This change will also require updating all subsequent references to
collIdin theMainfunction (lines 297, 299, 329) to usetableIdinstead.
28-28: Text updates look good with one minor suggestion.The terminology updates are consistent throughout. Consider lowercasing "Database" in line 181 to "Appwrite database" or being more specific with "Appwrite database table" for consistency.
Also applies to: 54-54, 141-141, 181-181
src/routes/blog/post/best-pagination-technique/+page.markdoc (1)
48-50: Text terminology updates are consistent and clear.All narrative text has been successfully updated to use table/row/column terminology. The changes maintain readability and technical accuracy throughout the blog post.
Optional: Consider replacing "sum column" (lines 48, 50) with "total count field" or "total field" for slightly clearer terminology, though "sum column" is technically correct.
Also applies to: 84-86, 124-124, 132-132, 178-180, 248-248
src/routes/blog/post/build-personal-crm-sveltekit/+page.markdoc (1)
99-117: upsertRows helper correctly follows bulk upsert API.Mapping contacts to
rowsand callingtablesDB.upsertRows({ databaseId, tableId, rows })matches the current TablesDB bulk upsert signature and will handle both new and existing rows via$id.(appwrite.io)You might optionally rethrow the original
errorinstead of wrapping it to preserve the stack, but the current error handling is acceptable.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (6)
src/routes/blog/post/3-things-you-can-build-with-go-runtime/+page.markdoc(9 hunks)src/routes/blog/post/best-pagination-technique/+page.markdoc(7 hunks)src/routes/blog/post/build-personal-crm-sveltekit/+page.markdoc(5 hunks)src/routes/blog/post/building-init-giveaway-app/+page.markdoc(11 hunks)src/routes/blog/post/track-document-order-with-sequence/+page.markdoc(11 hunks)src/routes/docs/tutorials/nextjs/step-6/+page.markdoc(3 hunks)
🧰 Additional context used
🧠 Learnings (8)
📓 Common learnings
Learnt from: ebenezerdon
Repo: appwrite/website PR: 2372
File: src/routes/docs/tutorials/react/step-6/+page.markdoc:70-75
Timestamp: 2025-09-05T19:35:53.943Z
Learning: In React tutorial files, the correct Appwrite database instance to import is `tablesDB` from "../appwrite", not `databases`. The import statement should be `import { tablesDB } from "../appwrite"` to match the usage throughout the React tutorial code.
Learnt from: ebenezerdon
Repo: appwrite/website PR: 2372
File: src/routes/docs/tutorials/nuxt/step-6/+page.markdoc:79-83
Timestamp: 2025-09-05T19:35:04.162Z
Learning: In Nuxt tutorial files, the correct Appwrite database instance to use is `tablesDB` (imported from "~/appwrite"), not `database`. All tablesDB method calls should use the object parameter format: listRows({ databaseId, tableId, queries }), createRow({ databaseId, tableId, rowId, data }), and deleteRow({ databaseId, tableId, rowId }).
📚 Learning: 2025-09-05T19:35:04.162Z
Learnt from: ebenezerdon
Repo: appwrite/website PR: 2372
File: src/routes/docs/tutorials/nuxt/step-6/+page.markdoc:79-83
Timestamp: 2025-09-05T19:35:04.162Z
Learning: In Nuxt tutorial files, the correct Appwrite database instance to use is `tablesDB` (imported from "~/appwrite"), not `database`. All tablesDB method calls should use the object parameter format: listRows({ databaseId, tableId, queries }), createRow({ databaseId, tableId, rowId, data }), and deleteRow({ databaseId, tableId, rowId }).
Applied to files:
src/routes/blog/post/building-init-giveaway-app/+page.markdocsrc/routes/blog/post/best-pagination-technique/+page.markdocsrc/routes/docs/tutorials/nextjs/step-6/+page.markdocsrc/routes/blog/post/track-document-order-with-sequence/+page.markdocsrc/routes/blog/post/3-things-you-can-build-with-go-runtime/+page.markdocsrc/routes/blog/post/build-personal-crm-sveltekit/+page.markdoc
📚 Learning: 2025-09-05T19:35:53.943Z
Learnt from: ebenezerdon
Repo: appwrite/website PR: 2372
File: src/routes/docs/tutorials/react/step-6/+page.markdoc:70-75
Timestamp: 2025-09-05T19:35:53.943Z
Learning: In React tutorial files, the correct Appwrite database instance to import is `tablesDB` from "../appwrite", not `databases`. The import statement should be `import { tablesDB } from "../appwrite"` to match the usage throughout the React tutorial code.
Applied to files:
src/routes/blog/post/building-init-giveaway-app/+page.markdocsrc/routes/blog/post/best-pagination-technique/+page.markdocsrc/routes/docs/tutorials/nextjs/step-6/+page.markdocsrc/routes/blog/post/track-document-order-with-sequence/+page.markdocsrc/routes/blog/post/3-things-you-can-build-with-go-runtime/+page.markdocsrc/routes/blog/post/build-personal-crm-sveltekit/+page.markdoc
📚 Learning: 2025-09-05T19:35:59.449Z
Learnt from: ebenezerdon
Repo: appwrite/website PR: 2372
File: src/routes/docs/tutorials/react-native/step-6/+page.markdoc:67-73
Timestamp: 2025-09-05T19:35:59.449Z
Learning: In React Native tutorials, the lib/appwrite.js file exports `tablesDB` (not `databases`), so imports should use `import { tablesDB } from "../lib/appwrite"` to match the export pattern established in step-3.
Applied to files:
src/routes/blog/post/building-init-giveaway-app/+page.markdocsrc/routes/blog/post/best-pagination-technique/+page.markdocsrc/routes/docs/tutorials/nextjs/step-6/+page.markdocsrc/routes/blog/post/track-document-order-with-sequence/+page.markdocsrc/routes/blog/post/3-things-you-can-build-with-go-runtime/+page.markdocsrc/routes/blog/post/build-personal-crm-sveltekit/+page.markdoc
📚 Learning: 2025-09-25T05:26:19.287Z
Learnt from: BretRen
Repo: appwrite/website PR: 2442
File: src/routes/docs/products/auth/email-password/+page.markdoc:22-31
Timestamp: 2025-09-25T05:26:19.287Z
Learning: Appwrite JavaScript SDKs now support object-based arguments instead of positional arguments as of 2025. The account.create method should be called with an object parameter containing userId, email, password, and optional name, rather than positional arguments. Positional arguments still work but are deprecated.
Applied to files:
src/routes/blog/post/building-init-giveaway-app/+page.markdocsrc/routes/blog/post/best-pagination-technique/+page.markdoc
📚 Learning: 2025-09-25T05:24:12.551Z
Learnt from: BretRen
Repo: appwrite/website PR: 2442
File: src/routes/docs/products/auth/email-password/+page.markdoc:50-56
Timestamp: 2025-09-25T05:24:12.551Z
Learning: The Appwrite `createEmailPasswordSession` method uses object parameters `{ email, password }` instead of positional arguments. This is consistent with other Account methods in Appwrite that also use object parameters.
Applied to files:
src/routes/blog/post/building-init-giveaway-app/+page.markdoc
📚 Learning: 2025-09-05T14:29:00.422Z
Learnt from: ItzNotABug
Repo: appwrite/website PR: 2362
File: src/routes/(marketing)/(components)/features.svelte:9-13
Timestamp: 2025-09-05T14:29:00.422Z
Learning: In the Appwrite website repository, fragment links (URLs with #anchor) in documentation are handled internally by the system and don't require explicit markdoc anchors or HTML id attributes in the source files.
Applied to files:
src/routes/blog/post/track-document-order-with-sequence/+page.markdoc
📚 Learning: 2025-09-24T08:55:57.959Z
Learnt from: amustaque97
Repo: appwrite/website PR: 2434
File: deploy/templates/deployment.yaml:0-0
Timestamp: 2025-09-24T08:55:57.959Z
Learning: In the Appwrite website Helm deployment, environment variables are managed through ConfigMap rather than direct Helm values injection, so security concerns about secrets in Deployment manifests don't apply to their setup.
Applied to files:
src/routes/blog/post/3-things-you-can-build-with-go-runtime/+page.markdoc
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
- GitHub Check: assets
- GitHub Check: build
- GitHub Check: tests
🔇 Additional comments (21)
src/routes/blog/post/track-document-order-with-sequence/+page.markdoc (2)
245-253: Code correctly uses object-args pattern.The
createRowcall properly uses the object-args pattern withAppwrite.ID.unique()for generating the row ID, matching current SDK best practices and addressing previous review feedback.
275-281: Code correctly uses object-args pattern.The
listRowscall properly uses the object-args pattern with thequeriesarray for ordering by$sequence, matching current SDK best practices and addressing previous review feedback.src/routes/blog/post/building-init-giveaway-app/+page.markdoc (5)
105-114: LGTM! TablesDB setup is correct.The Appwrite client configuration correctly uses TablesDB and exports the necessary instances. Note that OAuthProvider is not exported from this module, which will impact the import at line 126.
190-197: LGTM! Object-parameter signature is correct.The
listRowscall correctly uses the object-parameter format withdatabaseId,tableId, andqueriesproperties, consistent with the TablesDB API.
201-205: LGTM! Correctly accesses the rows property.The response handling correctly uses
entries.rowsto access the returned data, consistent with the new row-based API.
210-218: LGTM! Object-parameter signature is correct.The
createRowcall correctly uses the object-parameter format withdatabaseId,tableId,rowId, anddataproperties, consistent with the TablesDB API.
357-357: LGTM! Realtime path uses correct terminology.The subscription path correctly uses
tablesandrowsin the channel identifier, consistent with the new database terminology.src/routes/docs/tutorials/nextjs/step-6/+page.markdoc (4)
81-85: LGTM! Correct object parameter format.The
listRowscall correctly uses the object parameter format withdatabaseId,tableId, andqueriesarray, matching the new Tables API syntax. Based on learnings, this is the correct pattern for tablesDB method calls.
97-107: LGTM! Correct implementation of row-level permissions.The
createRowcall correctly uses the object parameter format withdatabaseId,tableId,rowId,data, andpermissions. The row-level permissions implementation aligns with the security approach described earlier in the tutorial (line 37), ensuring only the creator can update or delete their own ideas. Based on learnings, this is the correct pattern for tablesDB method calls.
116-120: LGTM! Correct object parameter format.The
deleteRowcall correctly uses the object parameter format withdatabaseId,tableId, androwId, matching the new Tables API syntax. Based on learnings, this is the correct pattern for tablesDB method calls.
62-62: Based on my verification, the import path in the Next.js step-6 tutorial is correct. Here's what I found:Key findings:
- Next.js step-3 instructs developers to create
lib/appwrite.tsat the project root and exporttablesDB- Next.js step-6 shows code for
hooks/useIdeas.tswhich correctly imports from'../lib/appwrite'- This relative path is correct: from
hooks/directory, going up one level (../) reacheslib/appwrite.ts- The import pattern matches the React Native tutorial (which also uses
'../lib/appwrite')- The
tablesDBexport name and API method calls all follow the correct Tables API syntaxThe original review comment's request for verification has been satisfied—no corrections are needed.
src/routes/blog/post/best-pagination-technique/+page.markdoc (4)
90-96: LGTM! SDK setup is correct.The import statement and client setup have been properly updated to use
ClientandTablesDBfrom the Appwrite Web SDK, which is the correct pattern for the new Tables API.
99-120: LGTM! API calls use correct object-parameter syntax.Both offset and cursor pagination examples correctly use the object-parameter signature for
tablesDB.listRows()withdatabaseId,tableId, andqueriesproperties. This aligns with the modern Appwrite SDK conventions.Based on learnings, the object-parameter format is the correct pattern for Appwrite JavaScript/TypeScript SDKs.
201-206: LGTM! REST API endpoints updated correctly.The REST API endpoints have been properly updated from
/collections/{collectionId}/documentsto/tables/{tableId}/rows, reflecting the new API structure.Also applies to: 269-274
164-164: LGTM! SQL table naming updated correctly.The SQL INSERT statement correctly references
_project_${config.projectId}_table_postsinstead of the old_collection_postsnaming convention, aligning with the new table-centric database structure.src/routes/blog/post/3-things-you-can-build-with-go-runtime/+page.markdoc (3)
348-348: Remove the review comment - scopes are correct and not redundant.According to Appwrite's official API documentation, the Tables API requires both
databases.*scopes and the newertables.*,columns.*, androws.*scopes. The scopes listed in line 348 (databases.read,databases.write,tables.read,tables.write,columns.read,columns.write,rows.read,rows.write) are complete and correct—not redundant. This is the required scope set for TablesDB operations using the Go SDK.
189-189: The import path is correct and verified.The import statement
"github.com/appwrite/sdk-for-go/tablesdb"at line 189 is the correct package path for the Appwrite Go SDK's TablesDB package, as confirmed by official documentation.
203-203: Perfect! I've now verified all the TablesDB API method names against the official Appwrite Go SDK documentation. Here are my findings:All method names and signatures are correct:
- ✓
GetTable(dbId, collId)- matches SDK signature- ✓
GetColumn(dbId, collId, attribId)- matches SDK signature- ✓
CreateTable(dbId, collId, "URLs", dbs.WithCreateTablePermissions(...))- matches SDK signature- ✓
CreateUrlColumn(dbId, collId, "longUrl", true, dbs.WithCreateUrlColumnArray(false))- matches SDK signatureCreateUrlColumn(databaseId, tableId, key, required, options...)- ✓
WithCreateTablePermissions(...)- verified helper option- ✓
WithCreateUrlColumnArray(false)- verified helper optionThe code in the blog post accurately uses the Appwrite Go SDK's TablesDB API with correct method names, parameter order, and types.
src/routes/blog/post/build-personal-crm-sveltekit/+page.markdoc (3)
78-79: TablesDB client and env wiring look correct.Using
TablesDBwithAPPWRITE_DATABASE_ID/APPWRITE_TABLE_IDand exposing adbwrapper matches the new Tables/Rows model and our other tutorials; no changes needed. Based on learnings, this is consistent with the sharedtablesDBpattern across frameworks.Also applies to: 85-97
120-131: deleteRow wrapper matches TablesDB deleteRow usage.Forwarding
rowIdviatablesDB.deleteRow({ databaseId, tableId, rowId: id })aligns with the TablesDB API and the DELETE handler’s expectation when anidis provided.(appwrite.io)
148-153: listRows wrapper and GET handler are consistent with TablesDB response.
listRowsdelegating totablesDB.listRows({ databaseId, tableId })and the GET handler returningjson(response.rows)match the TablesDB listRows response shape (rowsarray on the model).(appwrite.io)Also applies to: 186-190
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
src/routes/blog/post/how-to-optimize-your-appwrite-project/+page.markdoc (1)
253-253: Update method name to match new terminology.The FAQ still references the old
listDocuments()method, which is inconsistent with the updated API terminology used throughout the rest of this blog post.Apply this diff to fix the inconsistency:
-Use smart querying with `listDocuments()` and filters instead of multiple requests. Combine queries, enable pagination, and use the Realtime API for live updates instead of polling. This reduces server load and speeds up responses. +Use smart querying with `listRows()` and filters instead of multiple requests. Combine queries, enable pagination, and use the Realtime API for live updates instead of polling. This reduces server load and speeds up responses.
🧹 Nitpick comments (2)
src/routes/blog/post/improve-devex-dev-keys/+page.markdoc (2)
26-26: Tighten terminology: rows live in tables.To keep terminology fully aligned with TablesDB, consider explicitly mentioning the table here instead of “row in an Appwrite database,” e.g.:
-To test dev keys, I created a simple demo web app that sends 200 requests to create a new row in an Appwrite database. To set this app up, you must complete the following steps: +To test dev keys, I created a simple demo web app that sends 200 requests to create a new row in a table in an Appwrite database. To set this app up, you must complete the following steps:
30-35: Avoid suggesting file paths as Web platform origins.The Web platform origin should be an HTTP(S) hostname (like
http://localhost:3000), not a local file path. Suggest trimming that part to avoid confusing readers who openindex.htmlviafile://and still hit CORS.-Create a project (which will lead you to the project overview page). From the project Overview → Settings, add a Web platform with your app's origin (e.g., `http://localhost:3000` or the file path where you'll open your HTML) so Step 2 can execute without CORS errors. +Create a project (which will lead you to the project overview page). From the project Overview → Settings, add a Web platform with your app's origin (for example, `http://localhost:3000`) so Step 2 can execute without CORS errors.Everything else in Step 1 (1.8+ requirement, database/table/column wording, table permissions) looks consistent with the new TablesDB flow.
Also applies to: 40-41
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (5)
src/routes/blog/post/ci-cd-examples-in-appwrite/+page.markdoc(5 hunks)src/routes/blog/post/developer-tools-appwrite/+page.markdoc(1 hunks)src/routes/blog/post/how-to-optimize-your-appwrite-project/+page.markdoc(4 hunks)src/routes/blog/post/improve-devex-dev-keys/+page.markdoc(5 hunks)src/routes/docs/tutorials/sveltekit-csr-auth/step-3/+page.markdoc(3 hunks)
🧰 Additional context used
🧠 Learnings (9)
📓 Common learnings
Learnt from: ebenezerdon
Repo: appwrite/website PR: 2372
File: src/routes/docs/tutorials/react/step-6/+page.markdoc:70-75
Timestamp: 2025-09-05T19:35:53.943Z
Learning: In React tutorial files, the correct Appwrite database instance to import is `tablesDB` from "../appwrite", not `databases`. The import statement should be `import { tablesDB } from "../appwrite"` to match the usage throughout the React tutorial code.
Learnt from: ebenezerdon
Repo: appwrite/website PR: 2372
File: src/routes/docs/tutorials/nuxt/step-6/+page.markdoc:79-83
Timestamp: 2025-09-05T19:35:04.162Z
Learning: In Nuxt tutorial files, the correct Appwrite database instance to use is `tablesDB` (imported from "~/appwrite"), not `database`. All tablesDB method calls should use the object parameter format: listRows({ databaseId, tableId, queries }), createRow({ databaseId, tableId, rowId, data }), and deleteRow({ databaseId, tableId, rowId }).
📚 Learning: 2025-09-05T19:35:53.943Z
Learnt from: ebenezerdon
Repo: appwrite/website PR: 2372
File: src/routes/docs/tutorials/react/step-6/+page.markdoc:70-75
Timestamp: 2025-09-05T19:35:53.943Z
Learning: In React tutorial files, the correct Appwrite database instance to import is `tablesDB` from "../appwrite", not `databases`. The import statement should be `import { tablesDB } from "../appwrite"` to match the usage throughout the React tutorial code.
Applied to files:
src/routes/blog/post/developer-tools-appwrite/+page.markdocsrc/routes/blog/post/ci-cd-examples-in-appwrite/+page.markdocsrc/routes/blog/post/how-to-optimize-your-appwrite-project/+page.markdocsrc/routes/docs/tutorials/sveltekit-csr-auth/step-3/+page.markdocsrc/routes/blog/post/improve-devex-dev-keys/+page.markdoc
📚 Learning: 2025-09-05T19:35:04.162Z
Learnt from: ebenezerdon
Repo: appwrite/website PR: 2372
File: src/routes/docs/tutorials/nuxt/step-6/+page.markdoc:79-83
Timestamp: 2025-09-05T19:35:04.162Z
Learning: In Nuxt tutorial files, the correct Appwrite database instance to use is `tablesDB` (imported from "~/appwrite"), not `database`. All tablesDB method calls should use the object parameter format: listRows({ databaseId, tableId, queries }), createRow({ databaseId, tableId, rowId, data }), and deleteRow({ databaseId, tableId, rowId }).
Applied to files:
src/routes/blog/post/developer-tools-appwrite/+page.markdocsrc/routes/blog/post/ci-cd-examples-in-appwrite/+page.markdocsrc/routes/blog/post/how-to-optimize-your-appwrite-project/+page.markdocsrc/routes/docs/tutorials/sveltekit-csr-auth/step-3/+page.markdocsrc/routes/blog/post/improve-devex-dev-keys/+page.markdoc
📚 Learning: 2025-09-05T19:35:59.449Z
Learnt from: ebenezerdon
Repo: appwrite/website PR: 2372
File: src/routes/docs/tutorials/react-native/step-6/+page.markdoc:67-73
Timestamp: 2025-09-05T19:35:59.449Z
Learning: In React Native tutorials, the lib/appwrite.js file exports `tablesDB` (not `databases`), so imports should use `import { tablesDB } from "../lib/appwrite"` to match the export pattern established in step-3.
Applied to files:
src/routes/blog/post/developer-tools-appwrite/+page.markdocsrc/routes/blog/post/how-to-optimize-your-appwrite-project/+page.markdocsrc/routes/docs/tutorials/sveltekit-csr-auth/step-3/+page.markdocsrc/routes/blog/post/improve-devex-dev-keys/+page.markdoc
📚 Learning: 2025-09-24T09:00:37.016Z
Learnt from: amustaque97
Repo: appwrite/website PR: 2434
File: .github/workflows/staging.yml:104-111
Timestamp: 2025-09-24T09:00:37.016Z
Learning: The Appwrite website project uses private GHCR images, so imagePullSecret configuration cannot be removed from Kubernetes deployments.
Applied to files:
src/routes/blog/post/ci-cd-examples-in-appwrite/+page.markdoc
📚 Learning: 2025-09-25T12:18:00.841Z
Learnt from: amustaque97
Repo: appwrite/website PR: 2444
File: .github/workflows/production.yml:107-114
Timestamp: 2025-09-25T12:18:00.841Z
Learning: In the Appwrite website Kubernetes deployment, the team intentionally uses short-lived GITHUB_TOKEN for Docker pull secrets rather than long-lived registry credentials, as per amustaque97's explicit preference.
Applied to files:
src/routes/blog/post/ci-cd-examples-in-appwrite/+page.markdoc
📚 Learning: 2025-09-25T05:26:19.287Z
Learnt from: BretRen
Repo: appwrite/website PR: 2442
File: src/routes/docs/products/auth/email-password/+page.markdoc:22-31
Timestamp: 2025-09-25T05:26:19.287Z
Learning: Appwrite JavaScript SDKs now support object-based arguments instead of positional arguments as of 2025. The account.create method should be called with an object parameter containing userId, email, password, and optional name, rather than positional arguments. Positional arguments still work but are deprecated.
Applied to files:
src/routes/docs/tutorials/sveltekit-csr-auth/step-3/+page.markdocsrc/routes/blog/post/improve-devex-dev-keys/+page.markdoc
📚 Learning: 2025-10-24T22:17:14.669Z
Learnt from: stnguyen90
Repo: appwrite/website PR: 2520
File: src/routes/docs/advanced/self-hosting/production/updates/+page.markdoc:13-15
Timestamp: 2025-10-24T22:17:14.669Z
Learning: In Appwrite versioning, RC (Release Candidate) versions like `1.6.2-RC1` come before the stable release `1.6.2`. Documentation should recommend upgrading to stable versions, not RC versions.
Applied to files:
src/routes/blog/post/improve-devex-dev-keys/+page.markdoc
📚 Learning: 2025-09-25T05:24:12.551Z
Learnt from: BretRen
Repo: appwrite/website PR: 2442
File: src/routes/docs/products/auth/email-password/+page.markdoc:50-56
Timestamp: 2025-09-25T05:24:12.551Z
Learning: Appwrite v17+ uses object parameters consistently across Account methods. Both account.create({ userId, email, password }) and account.createEmailPasswordSession({ email, password }) use object parameters instead of positional arguments.
Applied to files:
src/routes/blog/post/improve-devex-dev-keys/+page.markdoc
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
- GitHub Check: build
- GitHub Check: assets
- GitHub Check: tests
🔇 Additional comments (9)
src/routes/blog/post/developer-tools-appwrite/+page.markdoc (1)
66-66: Previous review concern properly addressed.The description now correctly states that fetch-appwrite-types targets "Appwrite Databases/collections" and explicitly clarifies that it uses the legacy Databases API and does not support the new Tables API (rows/columns). This prevents reader confusion in the context of the broader terminology migration.
src/routes/docs/tutorials/sveltekit-csr-auth/step-3/+page.markdoc (1)
10-10: LGTM! TablesDB migration is correct and consistent.The changes correctly migrate from the old Databases API to the new TablesDB API:
- Narrative updated to reference
TablesDB- Import statement correctly uses
TablesDBinstead ofDatabases- Variable naming follows the convention (
tablesDBin camelCase)- Export properly exposes the
tablesDBinstanceThis aligns with the PR objectives and is consistent with TablesDB usage patterns across other tutorials.
Based on learnings, this matches the established pattern where tutorial files export
tablesDBinstances for use in subsequent steps.Also applies to: 20-20, 28-28, 33-33
src/routes/blog/post/ci-cd-examples-in-appwrite/+page.markdoc (3)
22-26: LGTM! Terminology update is consistent.The documentation and code example correctly reflect the updated terminology from collections to tables.
34-36: LGTM! Pull command updated consistently.The pull command correctly uses the new "tables" terminology.
120-124: LGTM! Jenkins pipeline updated consistently.The stage name and command are updated to match the new "tables" terminology, maintaining consistency with the YAML workflow example.
src/routes/blog/post/improve-devex-dev-keys/+page.markdoc (4)
64-65: Copy matches updated TablesDB terminology.The “200 rows” phrasing and
Add rowsbutton label are now consistent with the rest of the article and TablesDB naming. Looks good.
83-93: TablesDB initialization andcreateRowusage are correct and idiomatic.Using
new Appwrite.TablesDB(client)with the CDN build and callingcreateRowwith an object{ databaseId, tableId, rowId, data }matches the current SDK examples and the PR-wide move to object parameters. No changes needed here.
102-102: Good clarification of 429 vs CORS behavior.The explanation of seeing 429s once a Web platform is configured (and CORS errors otherwise, which go away with a dev key) accurately reflects how rate limits and dev keys interact with client SDK calls. Clear and helpful.
121-121: Final behavior description after adding dev key is accurate.With a dev key set on the client, it’s correct that all 200
createRowrequests can complete successfully without hitting the client-side rate limit. The narrative aligns with the earlier steps.
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (4)
src/routes/blog/post/announcing-go-support/+page.markdoc (1)
224-270: Missing models import (duplicate concern).This issue was already flagged in a previous review comment. The code embeds
models.Row(line 233) andmodels.RowList(line 239) without importing thegithub.com/appwrite/sdk-for-go/modelspackage in the import block (lines 224-230), which will cause a compilation error.src/routes/blog/post/simplify-your-data-management-with-relationships/+page.markdoc (1)
50-90: Fix minor wording issues in the one‑way relationship sectionTwo small text issues here:
- Line 50: grammatical typo “an column” → “a column”.
- Line 82: label should refer to the missing movie column (not “review” column) to match the explanation and examples. This was already flagged previously.
Suggested patch:
-...but the reviews table will not have an column containing the related movie. +...but the reviews table will not have a column containing the related movie. @@ -The review response, notably with no review column: +The review response, notably with no movie column:src/routes/blog/post/announcing-atomic-numeric-operations/+page.markdoc (1)
68-82: Verify the method signature fordecrementRowColumn.Similar to the
incrementRowColumnexample above, please verify that the positional parameter format is correct fordecrementRowColumn. This should be consistent with the Tables API syntax introduced in PR #2134.#!/bin/bash # Search for other usages of decrementRowColumn in the codebase to verify the correct signature rg -n -C3 'decrementRowColumn' --type=mdsrc/routes/blog/post/build-fullstack-svelte-appwrite/+page.markdoc (1)
534-539: Import mismatch:databasesimported buttablesDBused in code.The import on line 536 still references
databasesbut the code examples usetablesDB(lines 600, 650, 657, 690). Also,IDis missing from imports but used on line 660.<script lang="ts"> import { onMount } from 'svelte' - import { databases, account } from '$lib/appwrite' - import { DATABASE_ID, EXPENSES_TABLE_ID } from '$lib/appwrite' - import { Query, Permission, Role } from 'appwrite' + import { tablesDB, account, DATABASE_ID, EXPENSES_TABLE_ID } from '$lib/appwrite' + import { ID, Query, Permission, Role } from 'appwrite' import { formatDistanceToNow } from 'date-fns'
🧹 Nitpick comments (1)
src/routes/blog/post/appwrite-1.5-now-available-on-cloud/+page.markdoc (1)
209-216: Inconsistent API usage between the two examples in this section.The first example uses positional arguments with
db.listRows(...)while the second example (lines 221-230) uses object parameters withtablesDB.listRows({...}). For consistency and to match the SDK's preferred pattern, both examples should use the object-parameter syntax.-db.listRows( - '<DATABASE_ID>', - '<TABLE_ID>', - [ - Query.contains('content', ['happy', 'love']), - ] - ) +tablesDB.listRows({ + databaseId: '<DATABASE_ID>', + tableId: '<TABLE_ID>', + queries: [ + Query.contains('content', ['happy', 'love']), + ], +});Based on learnings, TablesDB methods should use the object parameter format.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (19)
src/routes/blog/post/ai-crystal-ball/+page.markdoc(6 hunks)src/routes/blog/post/announcing-atomic-numeric-operations/+page.markdoc(4 hunks)src/routes/blog/post/announcing-auto-increment-support/+page.markdoc(3 hunks)src/routes/blog/post/announcing-bulk-api/+page.markdoc(3 hunks)src/routes/blog/post/announcing-go-support/+page.markdoc(7 hunks)src/routes/blog/post/appwrite-1.5-now-available-on-cloud/+page.markdoc(1 hunks)src/routes/blog/post/appwrite-realtime-for-flutter/+page.markdoc(14 hunks)src/routes/blog/post/best-pagination-technique/+page.markdoc(7 hunks)src/routes/blog/post/build-fullstack-svelte-appwrite/+page.markdoc(10 hunks)src/routes/blog/post/build-personal-crm-sveltekit/+page.markdoc(9 hunks)src/routes/blog/post/building-init-giveaway-app/+page.markdoc(11 hunks)src/routes/blog/post/ci-cd-examples-in-appwrite/+page.markdoc(5 hunks)src/routes/blog/post/cors-error/+page.markdoc(2 hunks)src/routes/blog/post/customer-stories-smartbee/+page.markdoc(3 hunks)src/routes/blog/post/improve-devex-dev-keys/+page.markdoc(5 hunks)src/routes/blog/post/open-source-firebase-alternative/+page.markdoc(1 hunks)src/routes/blog/post/product-update-september/+page.markdoc(4 hunks)src/routes/blog/post/simplify-your-data-management-with-relationships/+page.markdoc(8 hunks)src/routes/blog/post/understand-data-queries/+page.markdoc(1 hunks)
✅ Files skipped from review due to trivial changes (2)
- src/routes/blog/post/cors-error/+page.markdoc
- src/routes/blog/post/open-source-firebase-alternative/+page.markdoc
🚧 Files skipped from review as they are similar to previous changes (2)
- src/routes/blog/post/ci-cd-examples-in-appwrite/+page.markdoc
- src/routes/blog/post/build-personal-crm-sveltekit/+page.markdoc
🧰 Additional context used
🧠 Learnings (12)
📓 Common learnings
Learnt from: ebenezerdon
Repo: appwrite/website PR: 2372
File: src/routes/docs/tutorials/react/step-6/+page.markdoc:70-75
Timestamp: 2025-09-05T19:35:53.943Z
Learning: In React tutorial files, the correct Appwrite database instance to import is `tablesDB` from "../appwrite", not `databases`. The import statement should be `import { tablesDB } from "../appwrite"` to match the usage throughout the React tutorial code.
Learnt from: ebenezerdon
Repo: appwrite/website PR: 2372
File: src/routes/docs/tutorials/nuxt/step-6/+page.markdoc:79-83
Timestamp: 2025-09-05T19:35:04.162Z
Learning: In Nuxt tutorial files, the correct Appwrite database instance to use is `tablesDB` (imported from "~/appwrite"), not `database`. All tablesDB method calls should use the object parameter format: listRows({ databaseId, tableId, queries }), createRow({ databaseId, tableId, rowId, data }), and deleteRow({ databaseId, tableId, rowId }).
Learnt from: ebenezerdon
Repo: appwrite/website PR: 2372
File: src/routes/docs/tutorials/react-native/step-6/+page.markdoc:67-73
Timestamp: 2025-09-05T19:35:59.449Z
Learning: In React Native tutorials, the lib/appwrite.js file exports `tablesDB` (not `databases`), so imports should use `import { tablesDB } from "../lib/appwrite"` to match the export pattern established in step-3.
Learnt from: ebenezerdon
Repo: appwrite/website PR: 2372
File: src/routes/docs/tutorials/react-native/step-6/+page.markdoc:67-73
Timestamp: 2025-09-05T19:35:59.449Z
Learning: In React Native tutorials, the lib/appwrite.js file exports `tablesDB` (not `databases`), so imports should use `import { tablesDB } from "../lib/appwrite"` to match the export pattern established in step-3.
Learnt from: stnguyen90
Repo: appwrite/website PR: 2520
File: src/routes/docs/advanced/self-hosting/production/updates/+page.markdoc:13-15
Timestamp: 2025-10-24T22:17:14.669Z
Learning: In Appwrite versioning, RC (Release Candidate) versions like `1.6.2-RC1` come before the stable release `1.6.2`. Documentation should recommend upgrading to stable versions, not RC versions.
📚 Learning: 2025-09-05T19:35:04.162Z
Learnt from: ebenezerdon
Repo: appwrite/website PR: 2372
File: src/routes/docs/tutorials/nuxt/step-6/+page.markdoc:79-83
Timestamp: 2025-09-05T19:35:04.162Z
Learning: In Nuxt tutorial files, the correct Appwrite database instance to use is `tablesDB` (imported from "~/appwrite"), not `database`. All tablesDB method calls should use the object parameter format: listRows({ databaseId, tableId, queries }), createRow({ databaseId, tableId, rowId, data }), and deleteRow({ databaseId, tableId, rowId }).
Applied to files:
src/routes/blog/post/simplify-your-data-management-with-relationships/+page.markdocsrc/routes/blog/post/understand-data-queries/+page.markdocsrc/routes/blog/post/announcing-auto-increment-support/+page.markdocsrc/routes/blog/post/announcing-atomic-numeric-operations/+page.markdocsrc/routes/blog/post/improve-devex-dev-keys/+page.markdocsrc/routes/blog/post/announcing-bulk-api/+page.markdocsrc/routes/blog/post/ai-crystal-ball/+page.markdocsrc/routes/blog/post/best-pagination-technique/+page.markdocsrc/routes/blog/post/appwrite-realtime-for-flutter/+page.markdocsrc/routes/blog/post/appwrite-1.5-now-available-on-cloud/+page.markdocsrc/routes/blog/post/building-init-giveaway-app/+page.markdocsrc/routes/blog/post/build-fullstack-svelte-appwrite/+page.markdoc
📚 Learning: 2025-09-05T19:35:53.943Z
Learnt from: ebenezerdon
Repo: appwrite/website PR: 2372
File: src/routes/docs/tutorials/react/step-6/+page.markdoc:70-75
Timestamp: 2025-09-05T19:35:53.943Z
Learning: In React tutorial files, the correct Appwrite database instance to import is `tablesDB` from "../appwrite", not `databases`. The import statement should be `import { tablesDB } from "../appwrite"` to match the usage throughout the React tutorial code.
Applied to files:
src/routes/blog/post/understand-data-queries/+page.markdocsrc/routes/blog/post/announcing-auto-increment-support/+page.markdocsrc/routes/blog/post/improve-devex-dev-keys/+page.markdocsrc/routes/blog/post/ai-crystal-ball/+page.markdocsrc/routes/blog/post/best-pagination-technique/+page.markdocsrc/routes/blog/post/appwrite-realtime-for-flutter/+page.markdocsrc/routes/blog/post/appwrite-1.5-now-available-on-cloud/+page.markdocsrc/routes/blog/post/building-init-giveaway-app/+page.markdocsrc/routes/blog/post/build-fullstack-svelte-appwrite/+page.markdoc
📚 Learning: 2025-09-05T19:35:59.449Z
Learnt from: ebenezerdon
Repo: appwrite/website PR: 2372
File: src/routes/docs/tutorials/react-native/step-6/+page.markdoc:67-73
Timestamp: 2025-09-05T19:35:59.449Z
Learning: In React Native tutorials, the lib/appwrite.js file exports `tablesDB` (not `databases`), so imports should use `import { tablesDB } from "../lib/appwrite"` to match the export pattern established in step-3.
Applied to files:
src/routes/blog/post/understand-data-queries/+page.markdocsrc/routes/blog/post/announcing-auto-increment-support/+page.markdocsrc/routes/blog/post/improve-devex-dev-keys/+page.markdocsrc/routes/blog/post/announcing-bulk-api/+page.markdocsrc/routes/blog/post/ai-crystal-ball/+page.markdocsrc/routes/blog/post/best-pagination-technique/+page.markdocsrc/routes/blog/post/appwrite-realtime-for-flutter/+page.markdocsrc/routes/blog/post/appwrite-1.5-now-available-on-cloud/+page.markdocsrc/routes/blog/post/building-init-giveaway-app/+page.markdocsrc/routes/blog/post/build-fullstack-svelte-appwrite/+page.markdoc
📚 Learning: 2025-10-24T22:17:14.669Z
Learnt from: stnguyen90
Repo: appwrite/website PR: 2520
File: src/routes/docs/advanced/self-hosting/production/updates/+page.markdoc:13-15
Timestamp: 2025-10-24T22:17:14.669Z
Learning: In Appwrite versioning, RC (Release Candidate) versions like `1.6.2-RC1` come before the stable release `1.6.2`. Documentation should recommend upgrading to stable versions, not RC versions.
Applied to files:
src/routes/blog/post/improve-devex-dev-keys/+page.markdoc
📚 Learning: 2025-09-25T05:26:19.287Z
Learnt from: BretRen
Repo: appwrite/website PR: 2442
File: src/routes/docs/products/auth/email-password/+page.markdoc:22-31
Timestamp: 2025-09-25T05:26:19.287Z
Learning: Appwrite JavaScript SDKs now support object-based arguments instead of positional arguments as of 2025. The account.create method should be called with an object parameter containing userId, email, password, and optional name, rather than positional arguments. Positional arguments still work but are deprecated.
Applied to files:
src/routes/blog/post/improve-devex-dev-keys/+page.markdocsrc/routes/blog/post/ai-crystal-ball/+page.markdocsrc/routes/blog/post/best-pagination-technique/+page.markdocsrc/routes/blog/post/building-init-giveaway-app/+page.markdocsrc/routes/blog/post/build-fullstack-svelte-appwrite/+page.markdoc
📚 Learning: 2025-09-25T05:24:12.551Z
Learnt from: BretRen
Repo: appwrite/website PR: 2442
File: src/routes/docs/products/auth/email-password/+page.markdoc:50-56
Timestamp: 2025-09-25T05:24:12.551Z
Learning: Appwrite v17+ uses object parameters consistently across Account methods. Both account.create({ userId, email, password }) and account.createEmailPasswordSession({ email, password }) use object parameters instead of positional arguments.
Applied to files:
src/routes/blog/post/improve-devex-dev-keys/+page.markdoc
📚 Learning: 2025-09-25T12:18:00.841Z
Learnt from: amustaque97
Repo: appwrite/website PR: 2444
File: .github/workflows/production.yml:107-114
Timestamp: 2025-09-25T12:18:00.841Z
Learning: In the Appwrite website Kubernetes deployment, the team intentionally uses short-lived GITHUB_TOKEN for Docker pull secrets rather than long-lived registry credentials, as per amustaque97's explicit preference.
Applied to files:
src/routes/blog/post/ai-crystal-ball/+page.markdoc
📚 Learning: 2025-09-24T08:55:57.959Z
Learnt from: amustaque97
Repo: appwrite/website PR: 2434
File: deploy/templates/deployment.yaml:0-0
Timestamp: 2025-09-24T08:55:57.959Z
Learning: In the Appwrite website Helm deployment, environment variables are managed through ConfigMap rather than direct Helm values injection, so security concerns about secrets in Deployment manifests don't apply to their setup.
Applied to files:
src/routes/blog/post/ai-crystal-ball/+page.markdocsrc/routes/blog/post/build-fullstack-svelte-appwrite/+page.markdoc
📚 Learning: 2025-09-24T09:16:03.075Z
Learnt from: amustaque97
Repo: appwrite/website PR: 2434
File: .github/workflows/staging.yml:117-131
Timestamp: 2025-09-24T09:16:03.075Z
Learning: In the Appwrite website deployment, environment variables are baked into the Docker image during the build stage using build-args, so creating a separate ConfigMap in the Kubernetes deployment job is unnecessary and redundant.
Applied to files:
src/routes/blog/post/ai-crystal-ball/+page.markdoc
📚 Learning: 2025-11-16T17:12:42.566Z
Learnt from: vfshera
Repo: appwrite/website PR: 2606
File: src/routes/docs/quick-starts/astro/+page.markdoc:61-86
Timestamp: 2025-11-16T17:12:42.566Z
Learning: In Astro, envField schema definition is correctly placed in astro.config.mjs by importing envField from "astro/config". The schema defines validation rules and types. The actual environment variables are then accessed in runtime code (routes, components, middleware) by importing from "astro:env/client" or "astro:env/server" virtual modules.
Applied to files:
src/routes/blog/post/ai-crystal-ball/+page.markdoc
📚 Learning: 2025-09-25T05:24:12.551Z
Learnt from: BretRen
Repo: appwrite/website PR: 2442
File: src/routes/docs/products/auth/email-password/+page.markdoc:50-56
Timestamp: 2025-09-25T05:24:12.551Z
Learning: The Appwrite `createEmailPasswordSession` method uses object parameters `{ email, password }` instead of positional arguments. This is consistent with other Account methods in Appwrite that also use object parameters.
Applied to files:
src/routes/blog/post/building-init-giveaway-app/+page.markdoc
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
- GitHub Check: tests
- GitHub Check: assets
- GitHub Check: build
🔇 Additional comments (33)
src/routes/blog/post/product-update-september/+page.markdoc (4)
28-28: Roles announcement link text fix looks goodSpelling and phrasing of the “Read the announcement.” link text are now correct and consistent with the rest of the post; URL is unchanged and appropriate.
65-69: CCPA section copy and link are clear and accurateThe updated CCPA description is concise, accurate at a high level, and the outbound link to the official CCPA resource plus the dedicated announcement are appropriate.
85-90: Terminology aligned with tables/columns modelThe heading and body now correctly use “table” and “columns,” matching the newer Tables API terminology while keeping the product-update narrative intact.
123-123: Closing teaser sentence reads wellThe updated sentence flows naturally and fits the tone of the “What’s to come” section without introducing any ambiguity.
src/routes/blog/post/understand-data-queries/+page.markdoc (3)
77-83: LGTM: Clean migration to TablesDB API.The import and instantiation correctly use the new
TablesDBclass, and the variable naming follows established patterns.
86-95: Well done: Object-style API correctly implemented.The OR operator example now uses the object parameter format with
queriesas an array, addressing the previous review feedback.
98-114: Excellent: Both AND and CONTAINS examples are correct.Both query examples consistently use the object parameter format and properly wrap query expressions in the
queriesarray, resolving all previous feedback.src/routes/blog/post/simplify-your-data-management-with-relationships/+page.markdoc (6)
4-14: Intro copy correctly reflects the new tables/rows terminologyThe updated description and opening paragraph consistently use “tables”, “columns”, and “rows” and align with the new Tables API/UI wording.
22-41: Relationship type definitions are consistent with table/row modelThe one-to-one / one-to-many / many-to-one / many-to-many explanations now use “tables” and “records” consistently and match the diagrams conceptually.
99-147: Two‑way relationship narrative and JSON examples look correctThe prose and both movie/review JSON examples correctly show the bidirectional relationship with
reviewson the movie andmovieon the review, and use$tableIdconsistently.
151-151: Trade‑offs paragraph between one‑way and two‑way is clearThe description of performance vs flexibility trade‑offs between one‑way and two‑way relationships is accurate and aligns with how these relationships behave.
159-169: On‑delete behavior section matches row terminologyThe restrict/cascade/set‑null descriptions correctly talk about parent/child rows and relationship cleanup, with terminology updated away from documents.
173-176: Closing paragraphs and docs link align with updated terminologyThe benefits section consistently uses “table management” and “rows”, and the call‑to‑action/link to the relationships docs remains appropriate.
src/routes/blog/post/announcing-atomic-numeric-operations/+page.markdoc (1)
4-4: LGTM! Terminology migration is consistent.The narrative text has been correctly updated from document-centric to row-centric terminology throughout the blog post, aligning with the new API/UI terminology.
Also applies to: 13-13, 15-15, 19-19, 23-23, 25-25, 89-89, 95-95, 99-99
src/routes/blog/post/customer-stories-smartbee/+page.markdoc (1)
4-4: Terminology updates look good.The narrative content correctly updates from "collection/document" to "table/row" terminology. The country name fix from "Columbia" to "Colombia" is also correct.
Also applies to: 40-41, 52-52
src/routes/blog/post/appwrite-1.5-now-available-on-cloud/+page.markdoc (1)
221-230: LGTM!This example correctly uses the object-parameter syntax for
tablesDB.listRows()which aligns with the SDK's preferred pattern.src/routes/blog/post/improve-devex-dev-keys/+page.markdoc (1)
83-99: LGTM!The code example correctly uses
Appwrite.TablesDBand the object-parameter syntax forcreateRow(). The terminology updates throughout the tutorial are consistent.src/routes/blog/post/building-init-giveaway-app/+page.markdoc (1)
191-198: LGTM!The
listRowsandcreateRowcalls correctly use the object-parameter syntax withdatabaseId,tableId,rowId, anddataproperties. This aligns with the SDK's preferred pattern.Also applies to: 211-219
src/routes/blog/post/announcing-bulk-api/+page.markdoc (1)
55-64: LGTM!The Bulk API example correctly uses
sdk.TablesDBwith the object-parameter syntax forcreateRows(). The terminology updates are consistent with the PR's migration objectives.src/routes/blog/post/announcing-auto-increment-support/+page.markdoc (1)
44-58: LGTM! SDK usage follows the object-parameter convention.The
listRowscall correctly uses the object-parameter signature withdatabaseId,tableId, andqueriesproperties, consistent with the new TablesDB API pattern. Based on learnings, this is the correct format for tablesDB method calls.src/routes/blog/post/best-pagination-technique/+page.markdoc (2)
90-120: LGTM! Both offset and cursor pagination examples correctly use object-parameter form.The
listRowscalls properly use the object-parameter signature withdatabaseId,tableId, andqueriesproperties. This addresses the past review comments and aligns with the SDK conventions.
164-164: Verify the table name in SQL query matches Appwrite's internal naming convention.The SQL query references
_project_${config.projectId}_table_posts. Ensure this naming pattern (_table_prefix) accurately reflects how Appwrite's MariaDB schema names tables internally after the terminology migration.src/routes/blog/post/ai-crystal-ball/+page.markdoc (3)
134-143: LGTM! Appwrite SDK setup correctly uses TablesDB.The import and instantiation of
TablesDBis correct, and the exportedtablesDBinstance follows the naming convention used throughout the tutorials.
282-306: LGTM! Database library methods use object-parameter signatures.Both
getRowandcreateRowcalls correctly use the object-parameter form withdatabaseId,tableId,rowId,data, andpermissionsproperties. This addresses the past review comments.
509-534: LGTM! Destiny table operations use correct object-parameter form.The
addDestinyandgetDestinyfunctions properly usecreateRowandgetRowwith object arguments includingtableIdandrowId.src/routes/blog/post/build-fullstack-svelte-appwrite/+page.markdoc (3)
600-605: LGTM!listRowscorrectly uses object-parameter signature.The SDK call properly uses the object form with
databaseId,tableId, andqueriesproperties. Past review comment addressed.
650-667: LGTM!updateRowandcreateRowcorrectly use object-parameter signatures.Both methods properly use the object form with
databaseId,tableId,rowId,data, andpermissionsproperties. Past review comments addressed.
690-694: LGTM!deleteRowcorrectly uses object-parameter signature.The method properly uses the object form with
databaseId,tableId, androwIdproperties. Past review comment addressed.src/routes/blog/post/appwrite-realtime-for-flutter/+page.markdoc (5)
31-48: LGTM!The terminology updates (collection → table, attributes → columns, etc.) are consistent with the new Appwrite UI/API naming conventions.
193-199: Good improvement: proper TextEditingController disposal.Adding
_nameController.dispose()prevents memory leaks. The dispose order (subscription first, then controller, then super) is appropriate.
205-235: LGTM!The TablesDB initialization and
listRowsAPI call follow the new terminology correctly. The named parameter syntax (databaseId:,tableId:) is appropriate for Dart.
268-299: LGTM!The
createRowanddeleteRowmethod calls with renamed parameters (tableId,rowId) are consistent with the new API terminology.
333-468: LGTM!The complete example consolidates all the changes consistently:
TablesDBclass withtablesDBinstance- Methods:
listRows,createRow,deleteRow- Parameters:
tableId,rowId- Response:
res.rows- Proper controller disposal
The example is well-structured and follows Flutter best practices.
src/routes/blog/post/announcing-atomic-numeric-operations/+page.markdoc
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (1)
src/routes/blog/post/ci-cd-examples-in-appwrite/+page.markdoc (1)
69-80: Fixpushexamples for functions and tables to match current CLI syntax.Two issues in this block:
Line [72]:
appwrite push function --function-id="function_id"
- CLI docs use the plural resource:
appwrite push functions ....- For non-interactive CI usage, they also include
--force(same section this article describes).Lines [79-80]:
appwrite push table --table-id="table_id"
- Command should be plural:
push tables.- The generic
--idflag is the documented way to target specific resources (tables, buckets, etc.), not--table-id.- This was already flagged in an earlier review and remains inconsistent with the official CLI docs.
Consider updating the examples like this:
Push a function: ```bash -appwrite push function --function-id="function_id" +appwrite push functions --function-id "function_id" --forcePush a table:
-appwrite push table --table-id="table_id" +appwrite push tables --id "table_id" --forceThis keeps the examples aligned with both the non‑interactive guidance and the generic `push` command semantics. ```web Check the latest Appwrite CLI docs for the correct syntax of: 1) `appwrite push functions --function-id ... --force` for a single function. 2) `appwrite push tables --id "<TABLE_ID>" --force` for pushing specific tables by ID. Confirm that singular `push function` / `push table` and `--table-id` are not the recommended forms.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
src/routes/blog/post/build-fullstack-svelte-appwrite/+page.markdoc(10 hunks)src/routes/blog/post/ci-cd-examples-in-appwrite/+page.markdoc(5 hunks)
🧰 Additional context used
🧠 Learnings (9)
📓 Common learnings
Learnt from: ebenezerdon
Repo: appwrite/website PR: 2372
File: src/routes/docs/tutorials/react/step-6/+page.markdoc:70-75
Timestamp: 2025-09-05T19:35:53.943Z
Learning: In React tutorial files, the correct Appwrite database instance to import is `tablesDB` from "../appwrite", not `databases`. The import statement should be `import { tablesDB } from "../appwrite"` to match the usage throughout the React tutorial code.
Learnt from: ebenezerdon
Repo: appwrite/website PR: 2372
File: src/routes/docs/tutorials/nuxt/step-6/+page.markdoc:79-83
Timestamp: 2025-09-05T19:35:04.162Z
Learning: In Nuxt tutorial files, the correct Appwrite database instance to use is `tablesDB` (imported from "~/appwrite"), not `database`. All tablesDB method calls should use the object parameter format: listRows({ databaseId, tableId, queries }), createRow({ databaseId, tableId, rowId, data }), and deleteRow({ databaseId, tableId, rowId }).
Learnt from: ebenezerdon
Repo: appwrite/website PR: 2372
File: src/routes/docs/tutorials/react-native/step-6/+page.markdoc:67-73
Timestamp: 2025-09-05T19:35:59.449Z
Learning: In React Native tutorials, the lib/appwrite.js file exports `tablesDB` (not `databases`), so imports should use `import { tablesDB } from "../lib/appwrite"` to match the export pattern established in step-3.
Learnt from: ebenezerdon
Repo: appwrite/website PR: 2372
File: src/routes/docs/tutorials/react-native/step-6/+page.markdoc:67-73
Timestamp: 2025-09-05T19:35:59.449Z
Learning: In React Native tutorials, the lib/appwrite.js file exports `tablesDB` (not `databases`), so imports should use `import { tablesDB } from "../lib/appwrite"` to match the export pattern established in step-3.
📚 Learning: 2025-09-05T19:35:04.162Z
Learnt from: ebenezerdon
Repo: appwrite/website PR: 2372
File: src/routes/docs/tutorials/nuxt/step-6/+page.markdoc:79-83
Timestamp: 2025-09-05T19:35:04.162Z
Learning: In Nuxt tutorial files, the correct Appwrite database instance to use is `tablesDB` (imported from "~/appwrite"), not `database`. All tablesDB method calls should use the object parameter format: listRows({ databaseId, tableId, queries }), createRow({ databaseId, tableId, rowId, data }), and deleteRow({ databaseId, tableId, rowId }).
Applied to files:
src/routes/blog/post/build-fullstack-svelte-appwrite/+page.markdocsrc/routes/blog/post/ci-cd-examples-in-appwrite/+page.markdoc
📚 Learning: 2025-09-05T19:35:59.449Z
Learnt from: ebenezerdon
Repo: appwrite/website PR: 2372
File: src/routes/docs/tutorials/react-native/step-6/+page.markdoc:67-73
Timestamp: 2025-09-05T19:35:59.449Z
Learning: In React Native tutorials, the lib/appwrite.js file exports `tablesDB` (not `databases`), so imports should use `import { tablesDB } from "../lib/appwrite"` to match the export pattern established in step-3.
Applied to files:
src/routes/blog/post/build-fullstack-svelte-appwrite/+page.markdocsrc/routes/blog/post/ci-cd-examples-in-appwrite/+page.markdoc
📚 Learning: 2025-09-05T19:35:53.943Z
Learnt from: ebenezerdon
Repo: appwrite/website PR: 2372
File: src/routes/docs/tutorials/react/step-6/+page.markdoc:70-75
Timestamp: 2025-09-05T19:35:53.943Z
Learning: In React tutorial files, the correct Appwrite database instance to import is `tablesDB` from "../appwrite", not `databases`. The import statement should be `import { tablesDB } from "../appwrite"` to match the usage throughout the React tutorial code.
Applied to files:
src/routes/blog/post/build-fullstack-svelte-appwrite/+page.markdocsrc/routes/blog/post/ci-cd-examples-in-appwrite/+page.markdoc
📚 Learning: 2025-09-24T08:55:57.959Z
Learnt from: amustaque97
Repo: appwrite/website PR: 2434
File: deploy/templates/deployment.yaml:0-0
Timestamp: 2025-09-24T08:55:57.959Z
Learning: In the Appwrite website Helm deployment, environment variables are managed through ConfigMap rather than direct Helm values injection, so security concerns about secrets in Deployment manifests don't apply to their setup.
Applied to files:
src/routes/blog/post/build-fullstack-svelte-appwrite/+page.markdoc
📚 Learning: 2025-09-25T05:26:19.287Z
Learnt from: BretRen
Repo: appwrite/website PR: 2442
File: src/routes/docs/products/auth/email-password/+page.markdoc:22-31
Timestamp: 2025-09-25T05:26:19.287Z
Learning: Appwrite JavaScript SDKs now support object-based arguments instead of positional arguments as of 2025. The account.create method should be called with an object parameter containing userId, email, password, and optional name, rather than positional arguments. Positional arguments still work but are deprecated.
Applied to files:
src/routes/blog/post/build-fullstack-svelte-appwrite/+page.markdoc
📚 Learning: 2025-09-24T09:00:37.016Z
Learnt from: amustaque97
Repo: appwrite/website PR: 2434
File: .github/workflows/staging.yml:104-111
Timestamp: 2025-09-24T09:00:37.016Z
Learning: The Appwrite website project uses private GHCR images, so imagePullSecret configuration cannot be removed from Kubernetes deployments.
Applied to files:
src/routes/blog/post/ci-cd-examples-in-appwrite/+page.markdoc
📚 Learning: 2025-09-25T12:18:00.841Z
Learnt from: amustaque97
Repo: appwrite/website PR: 2444
File: .github/workflows/production.yml:107-114
Timestamp: 2025-09-25T12:18:00.841Z
Learning: In the Appwrite website Kubernetes deployment, the team intentionally uses short-lived GITHUB_TOKEN for Docker pull secrets rather than long-lived registry credentials, as per amustaque97's explicit preference.
Applied to files:
src/routes/blog/post/ci-cd-examples-in-appwrite/+page.markdoc
📚 Learning: 2025-10-24T22:17:14.669Z
Learnt from: stnguyen90
Repo: appwrite/website PR: 2520
File: src/routes/docs/advanced/self-hosting/production/updates/+page.markdoc:13-15
Timestamp: 2025-10-24T22:17:14.669Z
Learning: In Appwrite versioning, RC (Release Candidate) versions like `1.6.2-RC1` come before the stable release `1.6.2`. Documentation should recommend upgrading to stable versions, not RC versions.
Applied to files:
src/routes/blog/post/ci-cd-examples-in-appwrite/+page.markdoc
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
- GitHub Check: assets
- GitHub Check: build
- GitHub Check: tests
🔇 Additional comments (7)
src/routes/blog/post/build-fullstack-svelte-appwrite/+page.markdoc (4)
64-65: Tables/rows terminology and env var wiring look consistent.The introduction of
PUBLIC_APPWRITE_TABLE_IDand the updated copy around creating a table, configuring its columns, permissions, and row security all align with the new Tables/rows model and match how other tutorials are being updated. No further changes needed here. Based on learnings, this matches the broader tablesDB/tableId migration pattern.Also applies to: 75-96
163-182: Appwrite client + TablesDB setup is correct and matches later usage.Importing
TablesDB, exportingtablesDB,EXPENSES_TABLE_ID, andDATABASE_ID, and wiring them to thePUBLIC_APPWRITE_*env vars is consistent with the new Tables API and with how the rest of this article consumes these values. Based on learnings, this mirrors the standardizedtablesDBsetup used in other framework tutorials.Also applies to: 184-187
536-537: TablesDB imports and row CRUD examples are aligned with the new API.Using
tablesDBfrom$lib/appwrite,EXPENSES_TABLE_ID, and the object-parameter forms oflistRows,updateRow,createRow, anddeleteRow(withresponse.rowsand explicit row-level permissions) is consistent with the new TablesDB patterns and keeps this Svelte example in sync with the updated terminology and SDK usage across the docs. Based on learnings, this matches the Nuxt/React tutorial updates that standardize ontablesDBwith object-style arguments for row operations.Also applies to: 599-605, 649-666, 682-683, 687-693
195-197: [Rewritten review comment]
[Classification tag]src/routes/blog/post/ci-cd-examples-in-appwrite/+page.markdoc (3)
41-61: GitHub Actions workflow and client configuration are consistent and secure.Renaming the job to "Sync Tables", triggering on
release: { types: [published] }, and adding a dedicated "Configure Appwrite client" step beforeappwrite pull tables --all --forceis correct and follows the documented non-interactive pattern using secrets forPROJECT_ID,ENDPOINT, andAPI_KEY. Theappwrite client --project-idsyntax with the--endpointand--keyflags is the recommended approach for non-interactive CLI configuration in CI/CD pipelines.
120-123: Jenkins "Push Tables" stage uses the recommended non‑interactive flags.The
stage('Push Tables')step usingappwrite push tables --all --forcefollows Appwrite's official CLI recommendations for non‑interactive pushing. The--allflag pushes all tables and the--forceflag skips confirmation prompts, both essential for CI/CD automation. (Note: The earlier GitHub Actions example in the file usesappwrite pull tables --all --force, which is the complement operation; both patterns correctly apply the same flags for their respective operations.)
22-35: Non‑interactive--force/--alltables examples are correct.The CLI snippets for
appwrite push tables --forceandappwrite pull tables --allalign with current Appwrite CLI documentation and are the recommended patterns for non-interactive CI/CD operations.
src/routes/blog/post/build-fullstack-svelte-appwrite/+page.markdoc
Outdated
Show resolved
Hide resolved
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
| dbs.CreateCollection( | ||
| dbs.CreateTable( | ||
| dbId, | ||
| collId, |
There was a problem hiding this comment.
collId should become tableId in these examples
| Query.contains('content', ['happy', 'love']) | ||
| ] | ||
| }); | ||
| db.listRows( |
There was a problem hiding this comment.
Can we also update this to follow the new syntax with objects?
| ```dart | ||
| dispose(){ | ||
| subscription?.close(); | ||
| _nameController.dispose(); |
There was a problem hiding this comment.
Suggestion from Coderabbit. It disposes the TextEditingController used for the input field
| **Mandatory Access Control (MAC)** uses a centralized authority to decide access, often based on classifications. It's strict and primarily used in environments requiring high security, such as government systems. | ||
|
|
||
| **Attribute-Based Access Control (ABAC)** relies on dynamic policies using attributes, such as user roles and environmental conditions. This model excels in environments needing fine-grained controls. | ||
| **Column-Based Access Control (CBAC)** relies on dynamic policies using columns, such as user roles and environmental conditions. This model excels in environments needing fine-grained controls. |
There was a problem hiding this comment.
ABAC is a standard access control model; the term has nothing to do with Appwrite Databases
There was a problem hiding this comment.
Got it. corrected
| ``` | ||
|
|
||
| The review response, notably with no review attribute: | ||
| The review response, notably with no review column: |
| ## **Flexibility and schema design in NoSQL** | ||
|
|
||
| One major benefit of NoSQL databases is their ability to work with varied data models. Without a set structure, NoSQL databases can adjust quickly to changing requirements, which can be very useful in projects with evolving data. For example, NoSQL's flexibility makes it easy to add new data attributes on the fly, unlike SQL databases, where major changes may require extra setup. | ||
| One major benefit of NoSQL databases is their ability to work with varied data models. Without a set structure, NoSQL databases can adjust quickly to changing requirements, which can be very useful in projects with evolving data. For example, NoSQL's flexibility makes it easy to add new data columns on the fly, unlike SQL databases, where major changes may require extra setup. |
There was a problem hiding this comment.
Columns is incorrect here since we're talking about NoSQL
It should be attributes
Co-authored-by: Aditya Oberai <adityaoberai1@gmail.com>
Co-authored-by: Aditya Oberai <adityaoberai1@gmail.com>
Co-authored-by: Aditya Oberai <adityaoberai1@gmail.com>
Co-authored-by: Aditya Oberai <adityaoberai1@gmail.com>
Co-authored-by: Aditya Oberai <adityaoberai1@gmail.com>
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (3)
src/routes/blog/post/introducing-support-for-server-side-rendering/+page.markdoc (2)
121-121: Fix function declaration syntax error.The function declaration mixes
functionkeyword syntax with arrow function syntax, which is invalid JavaScript.Apply this diff to fix the syntax:
-export function createAdminClient() => { +export function createAdminClient() {
142-142: Remove incorrect.secretproperty access.The
sessionvariable fromcookies.get()is already the secret string itself (as set on line 170), not a session object. Accessing.secreton a string returnsundefined, breaking authentication.Apply this diff:
- client.setSession(session.secret) + client.setSession(session)src/routes/blog/post/offline-first-journal/+page.markdoc (1)
194-213: UseaddCollectionsinstead ofaddTablesin RxDB exampleRxDB's
RxDatabaseexposes.addCollections(), not.addTables(). Usingdb.addTableswill throw at runtime (addTables is not a function) when readers copy this snippet.Suggested fix:
- // Add tables - await db.addTables({ - entries: { // Name must match the table ID from Appwrite + // Add collections (this collection maps to your Appwrite `entries` table) + await db.addCollections({ + entries: { // Name must match the table ID from Appwrite schema: journalSchema } });
♻️ Duplicate comments (1)
src/routes/blog/post/offline-first-journal/+page.markdoc (1)
237-260: DeclarereplicationStateinstead of assigning to an undeclared variableIn an ES module,
replicationState = replicateAppwrite({ ... })withoutconst/letwill throw aReferenceError; the RxDB/Appwrite examples declare this as a localconst replicationState = replicateAppwrite(...). (rxdb.info)Update the block to declare it locally:
- // Start replication - replicationState = replicateAppwrite({ + // Start replication + const replicationState = replicateAppwrite({ replicationIdentifier: 'journals-replication', client, databaseId: appwriteConfig.databaseId, collectionId: appwriteConfig.collectionId, deletedField: 'deleted', collection: db.entries, pull: { batchSize: 25 // Can be updated }, push: { batchSize: 25 // Can be updated } });
🧹 Nitpick comments (1)
src/routes/blog/post/best-pagination-technique/+page.markdoc (1)
92-99: Web SDK example now correctly uses Client + TablesDB and objectlistRows
- Importing
{ Client, TablesDB, Query }from"appwrite", instantiatingnew Client(), and passing it intonew TablesDB(client)is consistent with the current Web SDK pattern.- Both offset and cursor examples now use the object‑parameter
tablesDB.listRows({ databaseId, tableId, queries })signature withQuery.limit,Query.offset, andQuery.cursorAfter, which aligns with the object‑based API style in other tutorials (React/Nuxt/React Native).- The explanatory text at Line 126 correctly describes offset vs. cursor usage; if you want to be extra explicit, you could consider:
-Right after, we write the exact same list rows query, but this time using `cursor` instead of offset pagination. +Right after, we write the exact same `listRows` query, but this time using a cursor instead of offset pagination.Optional, but it tightens the terminology around the SDK method name.
Also applies to: 101-109, 113-121, 126-126
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (8)
src/routes/blog/post/3-things-you-can-build-with-go-runtime/+page.markdoc(9 hunks)src/routes/blog/post/appwrite-1.5-now-available-on-cloud/+page.markdoc(1 hunks)src/routes/blog/post/appwrite-realtime-for-flutter/+page.markdoc(13 hunks)src/routes/blog/post/best-pagination-technique/+page.markdoc(8 hunks)src/routes/blog/post/introducing-support-for-server-side-rendering/+page.markdoc(1 hunks)src/routes/blog/post/offline-first-journal/+page.markdoc(10 hunks)src/routes/blog/post/role-based-access-control-with-appwrite/+page.markdoc(4 hunks)src/routes/blog/post/sql-vs-nosql/+page.markdoc(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- src/routes/blog/post/role-based-access-control-with-appwrite/+page.markdoc
🧰 Additional context used
🧠 Learnings (9)
📓 Common learnings
Learnt from: ebenezerdon
Repo: appwrite/website PR: 2372
File: src/routes/docs/tutorials/react/step-6/+page.markdoc:70-75
Timestamp: 2025-09-05T19:35:53.943Z
Learning: In React tutorial files, the correct Appwrite database instance to import is `tablesDB` from "../appwrite", not `databases`. The import statement should be `import { tablesDB } from "../appwrite"` to match the usage throughout the React tutorial code.
Learnt from: ebenezerdon
Repo: appwrite/website PR: 2372
File: src/routes/docs/tutorials/nuxt/step-6/+page.markdoc:79-83
Timestamp: 2025-09-05T19:35:04.162Z
Learning: In Nuxt tutorial files, the correct Appwrite database instance to use is `tablesDB` (imported from "~/appwrite"), not `database`. All tablesDB method calls should use the object parameter format: listRows({ databaseId, tableId, queries }), createRow({ databaseId, tableId, rowId, data }), and deleteRow({ databaseId, tableId, rowId }).
Learnt from: ebenezerdon
Repo: appwrite/website PR: 2372
File: src/routes/docs/tutorials/react-native/step-6/+page.markdoc:67-73
Timestamp: 2025-09-05T19:35:59.449Z
Learning: In React Native tutorials, the lib/appwrite.js file exports `tablesDB` (not `databases`), so imports should use `import { tablesDB } from "../lib/appwrite"` to match the export pattern established in step-3.
Learnt from: ebenezerdon
Repo: appwrite/website PR: 2372
File: src/routes/docs/tutorials/react-native/step-6/+page.markdoc:67-73
Timestamp: 2025-09-05T19:35:59.449Z
Learning: In React Native tutorials, the lib/appwrite.js file exports `tablesDB` (not `databases`), so imports should use `import { tablesDB } from "../lib/appwrite"` to match the export pattern established in step-3.
📚 Learning: 2025-09-25T05:24:12.551Z
Learnt from: BretRen
Repo: appwrite/website PR: 2442
File: src/routes/docs/products/auth/email-password/+page.markdoc:50-56
Timestamp: 2025-09-25T05:24:12.551Z
Learning: The Appwrite `createEmailPasswordSession` method uses object parameters `{ email, password }` instead of positional arguments. This is consistent with other Account methods in Appwrite that also use object parameters.
Applied to files:
src/routes/blog/post/introducing-support-for-server-side-rendering/+page.markdoc
📚 Learning: 2025-09-25T05:24:12.551Z
Learnt from: BretRen
Repo: appwrite/website PR: 2442
File: src/routes/docs/products/auth/email-password/+page.markdoc:50-56
Timestamp: 2025-09-25T05:24:12.551Z
Learning: Appwrite v17+ uses object parameters for Account methods including createEmailPasswordSession({ email, password }) instead of positional arguments. This is consistent across the Account API methods like account.create({ userId, email, password }).
Applied to files:
src/routes/blog/post/introducing-support-for-server-side-rendering/+page.markdoc
📚 Learning: 2025-09-25T05:24:12.551Z
Learnt from: BretRen
Repo: appwrite/website PR: 2442
File: src/routes/docs/products/auth/email-password/+page.markdoc:50-56
Timestamp: 2025-09-25T05:24:12.551Z
Learning: Appwrite v17+ uses object parameters consistently across Account methods. Both account.create({ userId, email, password }) and account.createEmailPasswordSession({ email, password }) use object parameters instead of positional arguments.
Applied to files:
src/routes/blog/post/introducing-support-for-server-side-rendering/+page.markdoc
📚 Learning: 2025-09-25T05:26:19.287Z
Learnt from: BretRen
Repo: appwrite/website PR: 2442
File: src/routes/docs/products/auth/email-password/+page.markdoc:22-31
Timestamp: 2025-09-25T05:26:19.287Z
Learning: Appwrite JavaScript SDKs now support object-based arguments instead of positional arguments as of 2025. The account.create method should be called with an object parameter containing userId, email, password, and optional name, rather than positional arguments. Positional arguments still work but are deprecated.
Applied to files:
src/routes/blog/post/introducing-support-for-server-side-rendering/+page.markdocsrc/routes/blog/post/best-pagination-technique/+page.markdoc
📚 Learning: 2025-09-05T19:35:04.162Z
Learnt from: ebenezerdon
Repo: appwrite/website PR: 2372
File: src/routes/docs/tutorials/nuxt/step-6/+page.markdoc:79-83
Timestamp: 2025-09-05T19:35:04.162Z
Learning: In Nuxt tutorial files, the correct Appwrite database instance to use is `tablesDB` (imported from "~/appwrite"), not `database`. All tablesDB method calls should use the object parameter format: listRows({ databaseId, tableId, queries }), createRow({ databaseId, tableId, rowId, data }), and deleteRow({ databaseId, tableId, rowId }).
Applied to files:
src/routes/blog/post/offline-first-journal/+page.markdocsrc/routes/blog/post/3-things-you-can-build-with-go-runtime/+page.markdocsrc/routes/blog/post/appwrite-realtime-for-flutter/+page.markdocsrc/routes/blog/post/appwrite-1.5-now-available-on-cloud/+page.markdocsrc/routes/blog/post/best-pagination-technique/+page.markdoc
📚 Learning: 2025-09-05T19:35:53.943Z
Learnt from: ebenezerdon
Repo: appwrite/website PR: 2372
File: src/routes/docs/tutorials/react/step-6/+page.markdoc:70-75
Timestamp: 2025-09-05T19:35:53.943Z
Learning: In React tutorial files, the correct Appwrite database instance to import is `tablesDB` from "../appwrite", not `databases`. The import statement should be `import { tablesDB } from "../appwrite"` to match the usage throughout the React tutorial code.
Applied to files:
src/routes/blog/post/offline-first-journal/+page.markdocsrc/routes/blog/post/3-things-you-can-build-with-go-runtime/+page.markdocsrc/routes/blog/post/appwrite-realtime-for-flutter/+page.markdocsrc/routes/blog/post/appwrite-1.5-now-available-on-cloud/+page.markdocsrc/routes/blog/post/best-pagination-technique/+page.markdoc
📚 Learning: 2025-09-05T19:35:59.449Z
Learnt from: ebenezerdon
Repo: appwrite/website PR: 2372
File: src/routes/docs/tutorials/react-native/step-6/+page.markdoc:67-73
Timestamp: 2025-09-05T19:35:59.449Z
Learning: In React Native tutorials, the lib/appwrite.js file exports `tablesDB` (not `databases`), so imports should use `import { tablesDB } from "../lib/appwrite"` to match the export pattern established in step-3.
Applied to files:
src/routes/blog/post/offline-first-journal/+page.markdocsrc/routes/blog/post/appwrite-realtime-for-flutter/+page.markdocsrc/routes/blog/post/appwrite-1.5-now-available-on-cloud/+page.markdocsrc/routes/blog/post/best-pagination-technique/+page.markdoc
📚 Learning: 2025-09-24T08:55:57.959Z
Learnt from: amustaque97
Repo: appwrite/website PR: 2434
File: deploy/templates/deployment.yaml:0-0
Timestamp: 2025-09-24T08:55:57.959Z
Learning: In the Appwrite website Helm deployment, environment variables are managed through ConfigMap rather than direct Helm values injection, so security concerns about secrets in Deployment manifests don't apply to their setup.
Applied to files:
src/routes/blog/post/offline-first-journal/+page.markdocsrc/routes/blog/post/3-things-you-can-build-with-go-runtime/+page.markdoc
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
- GitHub Check: assets
- GitHub Check: tests
- GitHub Check: build
🔇 Additional comments (22)
src/routes/blog/post/introducing-support-for-server-side-rendering/+page.markdoc (1)
37-37: Already addressed in previous review.This change from "secret column" to "secret property" was correctly identified and addressed in commit eee38a8.
src/routes/blog/post/appwrite-realtime-for-flutter/+page.markdoc (8)
4-4: LGTM! Description accurately reflects the tutorial content.The updated description clearly communicates that the tutorial covers Appwrite's Realtime API.
31-48: LGTM! Setup instructions correctly updated to new terminology.The database setup instructions accurately reflect the new UI with tables, columns, and table IDs instead of collections, attributes, and collection IDs.
206-218: LGTM! TablesDB initialization follows the new API correctly.The code properly:
- Declares and initializes the TablesDB instance
- Updates variable names from
itemsCollectiontoitemsTable- Initializes the client with appropriate placeholders for tutorial purposes
269-281: LGTM! CRUD operations correctly updated to new TablesDB API.The code properly transitions:
createDocument→createRowwithtableIdandrowIdparametersdeleteDocument→deleteRowwithtableIdandrowIdparameters- Uses
ID.unique()for row generation (consistent with previous document ID pattern)All method calls use appropriate named parameters for Flutter/Dart.
Also applies to: 286-299
303-471: LGTM! Complete example consolidates all TablesDB API updates consistently.The full code example correctly implements:
- TablesDB initialization and usage throughout
- Consistent variable naming (
itemsTable,tablesDB)- All CRUD operations with new API methods (
listRows,createRow,deleteRow)- Realtime subscription to
'rows'channel- Proper resource cleanup with controller disposal
The example provides a working reference that matches all the code snippets presented earlier in the tutorial.
473-507: LGTM! Conclusion and FAQs appropriately updated.The conclusion correctly references Flutter and Appwrite Realtime. The FAQs use "documents" in a generic conceptual sense when discussing general data security and patterns, which is appropriate for explaining concepts to readers regardless of specific API terminology.
237-264: Realtime channel naming is correct.The subscription to the
'rows'channel is the correct identifier for listening to global row events across all databases and tables in the Tables API. The comment accurately describes this behavior, and the event handling logic appropriately checks for.createand.deletesuffixes, which are valid event types in the Realtime API.
221-235: The code correctly uses the TablesDB API.The
tablesDB.listRows()call is correct and matches the Appwrite Flutter SDK signature. The named parametersdatabaseIdandtableIdare accurate, and the response handling viares.rows.map((e) => e.data)properly accesses the row list and extracts row data.src/routes/blog/post/best-pagination-technique/+page.markdoc (4)
48-50: Offset‑pagination explanation looks good and matches suggested wordingThe revised description of the
sumcolumn andlastPage = ceil(sum / limit)is clear, technically accurate, and aligns with the earlier review suggestion.
84-88: Tables/TablesDB introduction is consistent with new terminologyThe updated paragraph correctly frames Appwrite Database in terms of tables, rows, columns, and indexes, and the mention of the TablesDB client and
listRowsnicely bridges into the code samples. This matches the newer TablesDB‑centric model used elsewhere in the docs.
203-203: REST endpoints updated correctly to Tables/rows in k6 scriptsSwitching the k6 HTTP calls from
/collections/posts/documentsto/tables/posts/rowskeeps the benchmark code consistent with the new Tables/Rows REST API paths used earlier in the article. Headers and query construction remain unchanged, so the behavioral intent of the benchmark is preserved.Also applies to: 271-271
338-338: Additional cursor‑pagination resource is a nice complementThe new “How to Implement Cursor Pagination Like a Pro” link is relevant and rounds out the resources list without conflicting with the article’s guidance.
src/routes/blog/post/appwrite-1.5-now-available-on-cloud/+page.markdoc (2)
28-32: Terminology and copy adjustments look correct“row deletion” and the global environment-variable wording now read clearly and align with the updated Tables/Rows mental model. No further changes needed here.
209-213: JS TablesDB examples now match the object-arg Tables APIThe
tablesDB.listRows({ databaseId, tableId, queries })usage (includingQuery.containsandQuery.or) is consistent with the newer TablesDB JS API and with how the tutorials use it. This should avoid the earlier mismatch with positional-arg examples. Based on learnings, this is aligned with the preferred pattern across tutorials.Please just double-check against the specific JS SDK version this blog targets to ensure the object-arg signature remains current.
Also applies to: 219-227
src/routes/blog/post/3-things-you-can-build-with-go-runtime/+page.markdoc (2)
189-247: Go URL shortener sample correctly migrated to TablesDBThe helpers and handler now use
tablesdb.TablesDBwithGet/GetTable/GetColumn,Create/CreateTable/CreateUrlColumn, andCreateRow/GetRowin a way that matches the current Go TablesDB SDK. PassingtablesDBintoInitialiseDatabaseand usingrow.Decodefor the GET flow is coherent, and the scopes list at the end covers all the database/table/column/row operations used. Based on learnings, this keeps the Go sample in line with the broader TablesDB migration.If you haven’t already, confirm against the exact
github.com/appwrite/sdk-for-goversion pinned in your examples to ensureWithCreateTablePermissionsand the other options accept the slice types you’re passing.Also applies to: 279-305, 329-338, 348-348
28-32: Prose updates line up with new terminologyReferences to events (“row deletion”), global env vars, and the function descriptions (chatbot, HTML resume, URL shortener storing data in an Appwrite database/table) all read cleanly and are consistent with the new Tables/Rows framing. No editorial or technical issues here.
Also applies to: 54-54, 141-141, 181-181
src/routes/blog/post/sql-vs-nosql/+page.markdoc (1)
59-64: Revised SQL/NoSQL schema wording is now domain-correctUsing “attributes” for NoSQL and “columns in SQL databases” for schema changes correctly differentiates the two models and aligns with previous feedback about terminology. The locking/downtime explanation for SQL migrations is accurate.
src/routes/blog/post/offline-first-journal/+page.markdoc (4)
45-60: Terminology updates around databases, tables, and columns look correctUsing the Databases page, table creation, and the Columns tab matches the current Appwrite console terminology after the collections → tables migration. (linkedin.com)
106-125: Env var and config renames are internally consistent
PUBLIC_APPWRITE_TABLE_IDis imported and wired into bothappwriteConfig.tableIdandappwriteConfig.collectionId, so the configuration stays consistent while supporting both naming styles; no issues here.
142-155: Verifydatabase(s).jsfilename vs import pathThe text tells readers to create
src/lib/databases.js, but later imports use'$lib/database.js'(singular). One of these is likely off; if someone follows the tutorial verbatim, the import will fail unless the file and path names match. Please align the filename and import path with whatever the demo app actually uses.Also applies to: 327-343
879-879: New integration link slug is correctLinking to
/integrations/replication-rxdbmatches the existing “Data replication with RxDB” integration entry in the catalog. (appwrite.io)
2 participants
What does this PR do?
Updates terminogies to to reflect new API/UI
Related PRs and Issues
Summary by CodeRabbit
✏️ Tip: You can customize this high-level summary in your review settings.