updates

Author: ymc9

versioned_docs/version-3.x/migrate-prisma.md

@@ -1,6 +1,6 @@
 ---
 description: How to migrate from a Prisma project to ZenStack v3
-sidebar_position: 11
+sidebar_position: 10
 ---
 
 import PackageInstall from './_components/PackageInstall';

versioned_docs/version-3.x/migrate-v2.md

@@ -1,6 +1,6 @@
 ---
 description: How to migrate from a ZenStack v2 project to v3
-sidebar_position: 10
+sidebar_position: 11
 ---
 
 import PackageInstall from './_components/PackageInstall';
@@ -9,40 +9,40 @@ import PackageInstall from './_components/PackageInstall';
 
 ## Overview
 
-ZenStack v3 is a major rewrite of v2, with a focus on simplicity and flexibility. It replaced Prisma ORM with its own ORM component built above [Kysely](https://kysely.dev/), resulting in a much more light-weighted architecture and the level extensibility that we couldn't achieve in v2.
+ZenStack v3 is a major rewrite of v2, with a focus on simplicity and flexibility. It replaced Prisma ORM with its own ORM component built on top of [Kysely](https://kysely.dev/), resulting in a much more lighter-weight architecture and the level of extensibility that we couldn't achieve in v2.
 
 A few v3 design decisions should make an upgrade much less painful:
 
-- The ZModel schema is essentially compatible with v2.
-- The ORM query API compatible with that of `PrismaClient`, thus compatible with v2.
+- The ZModel schema is compatible with v2.
+- The ORM query API is compatible with that of `PrismaClient`, thus compatible with v2.
 
 However, given the architectural changes, some effort is required to adapt to the new system. This guide will help you migrate an existing ZenStack v2 project.
 
 ## Compatibility Check
 
-Here are a few important items to verify before preparing your migration:
+Here are a few essential items to verify before preparing your migration:
 
 - Database support
 
-   V3 only supports PostgreSQL and SQLite databases for now. MySQL will be added later.
+   V3 currently only supports PostgreSQL and SQLite databases. MySQL will be added later.
 
-   For PostgreSQL, only native the traditional TCP-based connection is supported. Newer HTTP-based protocols like supported by newer providers like Neon and Prisma PG are not supported yet, but will be in the future.
+   For PostgreSQL, only native the traditional TCP-based connection is supported. Newer HTTP-based protocols, such as those supported by providers like Neon and Prisma PG, are not yet supported, but will be in the future.
 
 - Prisma feature gaps
 
    A few Prisma ORM's features are not implemented or not planned. Please check the [Prisma Feature Gaps](./migrate-prisma.md#feature-gaps) for details.
 
 - V2 feature gaps
 
-   A few ZenStack v2's features are not implemented. Some less popular features are planned to be dropped. Please check the [Feature Gaps](#feature-gaps) for details.
+   A few ZenStack v2 features are not implemented. Some less popular features are planned to be removed. Please check the [Feature Gaps](#feature-gaps) for details.
 
 ## Migrating Prisma
 
-Since ZenStack v3 is not based on Prisma ORM anymore, the first thing to do is to replace Prisma dependencies with ZenStack and update code where `PrismaClient` is created. Please follow the [Prisma Migration Guide](./migrate-prisma.md) for detailed instructions.
+Since ZenStack v3 is no longer based on Prisma ORM, the first step is to replace Prisma dependencies with ZenStack and update the code where `PrismaClient` is created. Please follow the [Prisma Migration Guide](./migrate-prisma.md) for detailed instructions.
 
 ## Migrating Access Policies
 
-Since v3's ZModel language is backward compatible with v2, no much work is needed in ZModel files. One change necessary is that, if you use access policies (`@@allow`, `@@deny`, etc.), they are now in self-contained plugins, and you need to install the package separately, add a plugin declaration in ZModel, and install the plugin at runtime.
+Since v3's ZModel language is backward compatible with v2, not much work is required in ZModel files. One necessary change is that, if you use access policies (`@@allow`, `@@deny`, etc.), they are now declared in self-contained plugins. You need to install the package separately, add a plugin declaration in ZModel, and then install the plugin at runtime.
 
 1. Install the package
 
@@ -86,7 +86,7 @@ async function processRequest(request: Request) {
 }
 ```
 
-The policy rules in ZModel are mostly backward compatible, except for a breaking change about post-update policies. In v3, post-update rules are expressed with its own "post-update" policy type and separate from regular "update" rules. Inside "post-update" rules, by default fields refer to the entity's "after-update" state, and you can use the `before()` function to refer to the "before-update" state. See [Post Update Rules](./orm/access-control/post-update.md) for more details.
+The policy rules in ZModel are mostly backward compatible, except for a breaking change about post-update policies. In v3, post-update rules are expressed with their own "post-update" policy type and separate from regular "update" rules. Inside "post-update" rules, by default, fields refer to the entity's "after-update" state, and you can use the `before()` function to refer to the "before-update" state. See [Post Update Rules](./orm/access-control/post-update.md) for more details.
 
 Here's a quick example for how to migrate:
 
@@ -144,9 +144,9 @@ function getClientForRequest(request: Request) {
 
 ## Migrating Client-Side Hooks
 
-V3 brings a new implementation of [TanStack Query](https://tanstack.com/query) implementation that doesn't require code generation. Instead, TS types are fully inferred from the schema type at compile time, and the runtime logic is based on interpretation of the schema object. As a result, the new integration becomes a simple library that you call, and no plugin is involved.
+V3 introduces a new implementation of [TanStack Query](https://tanstack.com/query) implementation that doesn't require code generation. Instead, TS types are fully inferred from the schema type at compile time, and the runtime logic is based on the interpretation of the schema object. As a result, the new integration becomes a simple library that you call, and no plugin is involved.
 
-To support such an architecture change. Query hooks are now grouped into an object that mirrors the API style of the ORM client. You need to adjust v2 code (that uses the flat `useFindMany[Model]` style hooks) into this new structure.
+To support such an architecture change. Query hooks are now grouped into an object that mirrors the API style of the ORM client. You need to adjust the v2 code (that uses the flat `useFindMany[Model]` style hooks) into this new structure.
 
 V2:
 ```ts
@@ -174,37 +174,41 @@ export function MyComponent() {
 
 ## Migration Custom Plugins
 
-V3 comes with a completely revised plugin system that offers great power and flexibility. You can check the concepts in the [Data Model Plugin](./modeling/plugin.md) and [ORM Plugin](./orm/plugins/) documentation.
+V3 comes with a completely revised plugin system that offers greater power and flexibility. You can check the concepts in the [Data Model Plugin](./modeling/plugin.md) and [ORM Plugin](./orm/plugins/) documentation.
 
 The plugin development document is still WIP. This part of the migration guide will be added later when it's ready.
 
 ## Feature Gaps
 
-This section lists v2 features that haven't been migrated to v3 yet, or that are planned to be removed in v3. Please feel free to share your thoughts about these decisions in [Discord](https://discord.gg/Ykhr738dUe) and we'll be happy to discuss them.
+This section lists v2 features that haven't been migrated to v3 yet, or that are planned to be removed in v3. Please feel free to share your thoughts about these decisions in [Discord](https://discord.gg/Ykhr738dUe), and we'll be happy to discuss them.
 
 ### Automatic password hashing
 
 The `@password` attribute is removed in v3. We believe most people will use a more sophisticated authentication system than a simple id/password mechanism.
 
 ### Field-level access control
 
-Not supported yet but will be added soon with some design changes.
+Not supported yet, but will be added soon with some design changes.
+
+### Data encryption
+
+Not supported yet, but will be added soon.
 
 ### Zod integration
 
-Not supported yet but will be added soon with some design changes.
+Not supported yet, but will be added soon with some design changes.
 
 ### Checking permissions without querying the database
 
 The [check()](/docs/guides/check-permission) feature is removed due to low popularity.
 
 ### tRPC integration
 
-[TRPC](https://trpc.io/) is TypeScript inference heavy, and stacking it over ZenStack generates additional complexities and pressure to the compiler. We're evaluating the best way to integrate it in v3, and no concrete plan is in place yet. At least there's no plan to directly migrate the code-generation based approach in v2.
+[TRPC](https://trpc.io/) is TypeScript-inference heavy, and stacking it over ZenStack generates additional complexities and pressure on the compiler. We're evaluating the best way to integrate it in v3, and no concrete plan is in place yet. At least there's no plan to migrate the code-generation-based approach in v2 directly.
 
 ### OpenAPI spec generation
 
-The [OpenAPI plugin](/docs/reference/plugins/openapi) is not migrated to v3 yet and will be added later with some redesign.
+The [OpenAPI plugin](/docs/reference/plugins/openapi) has not migrated to v3 yet and will be added later with some redesign.
 
 ### SWR integration
 
@@ -214,4 +218,4 @@ The [SWR plugin](https://swr.vercel.app/) is removed due to low popularity.
 
 ### Is data migration needed?
 
-No. From database schema point of view, v3 is fully backward compatible with v2.
+No. From the database schema point of view, v3 is fully backward-compatible with v2.

versioned_docs/version-3.x/roadmap.md

@@ -1,5 +1,5 @@
 ---
-sidebar_position: 11
+sidebar_position: 12
 ---
 
 # Roadmap