@venizia/ignis-docs 0.0.1-7 → 0.0.1-9

package/wiki/get-started/core-concepts/controllers.md

@@ -9,7 +9,7 @@ Controllers handle HTTP requests and return responses - they're your API endpoin
 Extend `BaseController` and use decorators to define routes:
 
 ```typescript
-import { BaseController, controller, get, jsonResponse, z } from '@venizia/ignis';
+import { BaseController, controller, get, jsonResponse, z, HTTP } from '@venizia/ignis';
 import { Context } from 'hono';
 
 @controller({ path: '/users' })
@@ -29,7 +29,7 @@ export class UserController extends BaseController {
     },
   })
   getAllUsers(c: Context) {
-    return c.json([{ id: '1', name: 'John Doe' }]);
+    return c.json([{ id: '1', name: 'John Doe' }], HTTP.ResultCodes.RS_2.Ok);
   }
 }
 ```
@@ -177,7 +177,7 @@ const GetUsersRoute = {
 this.defineRoute({
   configs: GetUsersRoute,
   handler: (c: TRouteContext<typeof GetUsersRoute>) => { // Return type is automatically inferred
-    return c.json([{ id: 1, name: 'John Doe' }]);
+    return c.json([{ id: 1, name: 'John Doe' }], HTTP.ResultCodes.RS_2.Ok);
   },
 });
 ```
@@ -187,7 +187,7 @@ this.defineRoute({
 This method offers a fluent API for defining routes, similar to `defineRoute`, but structured for chaining. It also benefits from `TRouteContext` for type safety.
 
 ```typescript
-import { jsonResponse, z, TRouteContext } from '@venizia/ignis';
+import { jsonResponse, z, TRouteContext, HTTP } from '@venizia/ignis';
 
 // ... inside the binding() method
 
@@ -205,7 +205,7 @@ this.bindRoute({
 }).to({
   handler: (c: TRouteContext<typeof GetUserByIdRoute>) => { // Return type is automatically inferred
     const { id } = c.req.param();
-    return c.json({ id: id, name: 'John Doe' });
+    return c.json({ id: id, name: 'John Doe' }, HTTP.ResultCodes.RS_2.Ok);
   },
 });
 ```
@@ -255,17 +255,17 @@ export class ConfigurationController extends _Controller {
 ```
 The `ControllerFactory.defineCrudController` method automatically sets up the following routes based on your entity schema:
 
-| Name | Method | Path | Description |
+| Route Name | Method | Path | Description |
 | :--- | :--- | :--- | :--- |
 | `count` | `GET` | `/count` | Get the number of records matching a filter. |
 | `find` | `GET` | `/` | Retrieve all records matching a filter. |
 | `findById` | `GET` | `/:id` | Retrieve a single record by its ID. |
 | `findOne` | `GET` | `/find-one` | Retrieve a single record matching a filter. |
 | `create` | `POST` | `/` | Create a new record. |
-| `updateById` | `PATCH` | `/:id` | Update a record by its ID. |
-| `updateAll` | `PATCH` | `/` | Update multiple records matching a filter. |
-| `deleteById` | `DELETE` | `/:id` | Delete a record by its ID. |
-| `deleteAll` | `DELETE` | `/` | Delete multiple records matching a filter. |
+| `updateById` | `PATCH` | `/:id` | Update a single record by its ID. |
+| `updateBy` | `PATCH` | `/` | Update multiple records matching a `where` filter. |
+| `deleteById` | `DELETE` | `/:id` | Delete a single record by its ID. |
+| `deleteBy` | `DELETE` | `/` | Delete multiple records matching a `where` filter. |
 
 :::info Customization
 The `ControllerFactory` is highly customizable. You can override the Zod schemas for any of the generated routes to add, remove, or modify fields for request validation and response shapes. You can also configure other behaviors, like making delete operations return the deleted records.
@@ -368,7 +368,7 @@ When you define Zod schemas in your route's `request` configuration (whether wit
 
 ```typescript
 import { z } from '@hono/zod-openapi';
-import { jsonContent, put } from '@venizia/ignis';
+import { jsonContent, put, HTTP } from '@venizia/ignis';
 
 // ... inside a controller class
 
@@ -397,7 +397,7 @@ updateUser(c: Context) {
     console.log('Notification is enabled.');
   }
 
-  return c.json({ success: true, id, ...userUpdateData });
+  return c.json({ success: true, id, ...userUpdateData }, HTTP.ResultCodes.RS_2.Ok);
 }
 ```
 
@@ -405,7 +405,7 @@ Using `c.req.valid()` is the recommended way to access request data as it ensure
 
 ```typescript
 import { z } from '@hono/zod-openapi';
-import { jsonContent, put, TRouteContext } from '@venizia/ignis';
+import { jsonContent, put, TRouteContext, HTTP } from '@venizia/ignis';
 
 // ... inside a controller class
 
@@ -434,7 +434,7 @@ updateUser(c: TRouteContext<typeof updateUserConfig>) {
     console.log('Notification is enabled.');
   }
 
-  return c.json({ success: true, id, ...userUpdateData });
+  return c.json({ success: true, id, ...userUpdateData }, HTTP.ResultCodes.RS_2.Ok);
 }
 ```
 

package/wiki/get-started/core-concepts/persistent.md

@@ -45,12 +45,10 @@ export type TUser = TTableObject<TUserSchema>;
 
 // 4. Create the Entity class, decorated with @model
 @model({ type: 'entity' })
-export class User extends BaseEntity<TUserSchema> {
-  static readonly TABLE_NAME = User.name;
-
-  constructor() {
-    super({ name: User.name, schema: userTable });
-  }
+export class User extends BaseEntity<typeof User.schema> {
+  static override schema = userTable;
+  static override relations = () => userRelations.definitions;
+  static override TABLE_NAME = 'User';
 }
 ```
 
@@ -158,12 +156,10 @@ export type TPostSchema = typeof postTable;
 export type TPost = TTableObject<TPostSchema>;
 
 @model({ type: 'entity' })
-export class Post extends BaseEntity<TPostSchema> {
-  static readonly TABLE_NAME = 'Post';
-
-  constructor() {
-    super({ name: Post.TABLE_NAME, schema: postTable });
-  }
+export class Post extends BaseEntity<typeof Post.schema> {
+  static override schema = postTable;
+  static override relations = () => postRelations.definitions;
+  static override TABLE_NAME = 'Post';
 }
 ```
 
@@ -286,12 +282,10 @@ export type TConfigurationSchema = typeof configurationTable;
 export type TConfiguration = TTableObject<TConfigurationSchema>;
 
 @model({ type: 'entity' })
-export class Configuration extends BaseEntity<TConfigurationSchema> {
-  static readonly TABLE_NAME = Configuration.name;
-
-  constructor() {
-    super({ name: Configuration.TABLE_NAME, schema: configurationTable });
-  }
+export class Configuration extends BaseEntity<typeof Configuration.schema> {
+  static override schema = configurationTable;
+  static override relations = () => configurationRelations.definitions;
+  static override TABLE_NAME = 'Configuration';
 }
 ```
 **Key Concepts:**
@@ -309,34 +303,14 @@ A DataSource is a class responsible for managing the connection to your database
 
 ### Creating and Configuring a DataSource
 
-A `DataSource` must be decorated with `@datasource`. **The most critical part** is correctly merging your table schemas and relations into a single object that Drizzle ORM can understand.
-
-#### ⚠️ Understanding Schema Merging (CRITICAL CONCEPT)
-
-This is one of the most important concepts in Ignis. If you don't get this right, your relations won't work.
-
-**The Problem:**
-Drizzle ORM needs to know about:
-1. Your table structures (e.g., `userTable`, `configurationTable`)
-2. The relationships between them (e.g., "Configuration belongs to User")
+A `DataSource` must be decorated with `@datasource`. The framework now supports **schema auto-discovery**, which means you no longer need to manually merge tables and relations!
 
-**The Solution:**
-You must merge both into a single `schema` object in your DataSource constructor.
+### Pattern 1: Auto-Discovery (Recommended)
 
-#### Step-by-Step Example
-
-Let's say you have two models: `User` and `Configuration`. Here's how to set up the DataSource:
+With auto-discovery, the schema is automatically built from your `@repository` decorators:
 
 ```typescript
 // src/datasources/postgres.datasource.ts
-import {
-  Configuration,
-  configurationTable,        // The table structure
-  configurationRelations,    // The relationships
-  User,
-  userTable,                 // The table structure
-  userRelations,             // The relationships
-} from '@/models/entities';
 import {
   BaseDataSource,
   datasource,
@@ -346,7 +320,6 @@ import {
 import { drizzle } from 'drizzle-orm/node-postgres';
 import { Pool } from 'pg';
 
-// Configuration interface for database connection
 interface IDSConfigs {
   connection: {
     host?: string;
@@ -357,12 +330,11 @@ interface IDSConfigs {
   };
 }
 
-@datasource()
+@datasource({ driver: 'node-postgres' })
 export class PostgresDataSource extends BaseDataSource<TNodePostgresConnector, IDSConfigs> {
   constructor() {
     super({
       name: PostgresDataSource.name,
-      driver: 'node-postgres',
       config: {
         connection: {
           host: process.env.APP_ENV_POSTGRES_HOST,
@@ -372,27 +344,14 @@ export class PostgresDataSource extends BaseDataSource<TNodePostgresConnector, I
           database: process.env.APP_ENV_POSTGRES_DATABASE,
         },
       },
-
-      // 🔥 CRITICAL: This is where you merge tables and relations
-      schema: Object.assign(
-        {},
-        // Step 1: Add your table schemas
-        {
-          [User.TABLE_NAME]: userTable,
-          [Configuration.TABLE_NAME]: configurationTable,
-        },
-        // Step 2: Spread the relations objects
-        userRelations.relations,
-        configurationRelations.relations,
-      ),
+      // No schema needed - auto-discovered from @repository decorators!
     });
   }
 
   override configure(): ValueOrPromise<void> {
-    // Pass the merged schema to Drizzle
     this.connector = drizzle({
       client: new Pool(this.settings.connection),
-      schema: this.schema, // This now contains both tables AND relations
+      schema: this.schema, // Auto-discovered schema
     });
   }
 
@@ -407,34 +366,24 @@ export class PostgresDataSource extends BaseDataSource<TNodePostgresConnector, I
 }
 ```
 
-#### Why This Pattern?
-
-**Without the relations merged in:**
-```typescript
-// ❌ WRONG - Relations won't work!
-schema: {
-  [User.TABLE_NAME]: userTable,
-  [Configuration.TABLE_NAME]: configurationTable,
-}
-```
+**How auto-discovery works:**
 
-**Result:** Your repository's `include` queries will fail. You won't be able to fetch related data.
+When you define repositories with both `model` and `dataSource`:
 
-**With tables and relations merged:**
 ```typescript
-// ✅ CORRECT - Relations work perfectly!
-schema: Object.assign(
-  {},
-  {
-    [User.TABLE_NAME]: userTable,
-    [Configuration.TABLE_NAME]: configurationTable,
-  },
-  userRelations.relations,
-  configurationRelations.relations,
-)
+@repository({ model: User, dataSource: PostgresDataSource })
+export class UserRepository extends DefaultCRUDRepository<typeof User.schema> {}
+
+@repository({ model: Configuration, dataSource: PostgresDataSource })
+export class ConfigurationRepository extends DefaultCRUDRepository<typeof Configuration.schema> {}
 ```
 
-**Result:** You can now do:
+The framework automatically:
+1. Registers each model-datasource binding
+2. Builds the combined schema (tables + relations) when `getSchema()` is called
+3. Makes all registered models available for relational queries
+
+**Result:** You can use `include` queries without any manual schema configuration:
 ```typescript
 const config = await configRepo.findOne({
   filter: {
@@ -445,53 +394,55 @@ const config = await configRepo.findOne({
 console.log(config.creator.name); // Access related User data
 ```
 
-#### Adding New Models to Your DataSource
-
-Every time you create a new model, you need to:
+### Pattern 2: Manual Schema (Full Control)
 
-1. Import its table and relations
-2. Add them to the schema object
+If you need explicit control over the schema, you can still provide it manually:
 
-**Example - Adding a `Post` model:**
 ```typescript
 import {
-  Post,
-  postTable,
-  postRelations,
-  // ... other models
+  Configuration, configurationTable, configurationRelations,
+  User, userTable, userRelations,
 } from '@/models/entities';
 
-// In your constructor:
-schema: Object.assign(
-  {},
-  {
-    [User.TABLE_NAME]: userTable,
-    [Configuration.TABLE_NAME]: configurationTable,
-    [Post.TABLE_NAME]: postTable, // Add the table
-  },
-  userRelations.relations,
-  configurationRelations.relations,
-  postRelations.relations, // Add the relations
-),
+@datasource({ driver: 'node-postgres' })
+export class PostgresDataSource extends BaseDataSource<TNodePostgresConnector, IDSConfigs> {
+  constructor() {
+    super({
+      name: PostgresDataSource.name,
+      config: { /* ... */ },
+      // Manually merge tables and relations using spread syntax
+      schema: {
+        [User.TABLE_NAME]: userTable,
+        [Configuration.TABLE_NAME]: configurationTable,
+        ...userRelations.relations,
+        ...configurationRelations.relations,
+      },
+    });
+  }
+
+  override configure(): ValueOrPromise<void> {
+    this.connector = drizzle({
+      client: new Pool(this.settings.connection),
+      schema: this.schema,
+    });
+  }
+}
 ```
 
-**Pro tip:** As your app grows, consider using a helper function to reduce boilerplate:
+### @datasource Decorator
 
 ```typescript
-function buildSchema(models: Array<{ table: any; relations: any; name: string }>) {
-  const tables = models.reduce((acc, m) => ({ ...acc, [m.name]: m.table }), {});
-  const relations = models.map(m => m.relations.relations);
-  return Object.assign({}, tables, ...relations);
-}
-
-// Usage:
-schema: buildSchema([
-  { name: User.TABLE_NAME, table: userTable, relations: userRelations },
-  { name: Configuration.TABLE_NAME, table: configurationTable, relations: configurationRelations },
-  { name: Post.TABLE_NAME, table: postTable, relations: postRelations },
-])
+@datasource({
+  driver: 'node-postgres',    // Required - database driver
+  autoDiscovery?: true        // Optional - defaults to true
+})
 ```
 
+| Option | Type | Default | Description |
+|--------|------|---------|-------------|
+| `driver` | `TDataSourceDriver` | - | Database driver name |
+| `autoDiscovery` | `boolean` | `true` | Enable/disable schema auto-discovery |
+
 ### Registering a DataSource
 
 Finally, register your `DataSource` with the application in `src/application.ts`.
@@ -520,29 +471,58 @@ Repositories abstract the data access logic. They use the configured `DataSource
 
 ### Creating a Repository
 
-A repository extends `DefaultCRUDRepository` (for full read/write operations), is decorated with `@repository`, and injects the `DataSource`.
+A repository extends `DefaultCRUDRepository` (for full read/write operations) and is decorated with `@repository`.
+
+**IMPORTANT:** Both `model` AND `dataSource` are required in `@repository` for schema auto-discovery. Without both, the model won't be registered and relational queries will fail.
+
+#### Pattern 1: Zero Boilerplate (Recommended)
+
+The simplest approach - dataSource is auto-injected from metadata:
 
 ```typescript
 // src/repositories/configuration.repository.ts
-import {
-  Configuration,
-  configurationRelations, // Import configurationRelations
-  TConfigurationSchema,
-} from '@/models/entities';
-import { IDataSource, inject, repository, DefaultCRUDRepository } from '@venizia/ignis';
+import { Configuration, TConfigurationSchema } from '@/models/entities';
+import { PostgresDataSource } from '@/datasources';
+import { repository, DefaultCRUDRepository } from '@venizia/ignis';
 
-// Decorator to mark this class as a repository for DI
-@repository({})
+@repository({ model: Configuration, dataSource: PostgresDataSource })
 export class ConfigurationRepository extends DefaultCRUDRepository<TConfigurationSchema> {
+  // No constructor needed - datasource auto-injected!
+
+  // Add custom methods as needed
+  async findByCode(code: string) {
+    return this.findOne({ filter: { where: { code } } });
+  }
+}
+```
+
+#### Pattern 2: Explicit @inject
+
+When you need constructor control (e.g., for read-only repositories or custom initialization):
+
+```typescript
+// src/repositories/user.repository.ts
+import { User } from '@/models/entities';
+import { PostgresDataSource } from '@/datasources';
+import { inject, repository, ReadableRepository } from '@venizia/ignis';
+
+@repository({ model: User, dataSource: PostgresDataSource })
+export class UserRepository extends ReadableRepository<typeof User.schema> {
   constructor(
-    // Inject the configured datasource
-    @inject({ key: 'datasources.PostgresDataSource' }) dataSource: IDataSource,
+    @inject({ key: 'datasources.PostgresDataSource' })
+    dataSource: PostgresDataSource,  // Must be concrete DataSource type, NOT 'any'
   ) {
-    // Pass the datasource, the model's Entity class, AND the relations definitions to the super constructor
-    super({ dataSource, entityClass: Configuration, relations: configurationRelations.definitions });
+    super(dataSource);
+  }
+
+  async findByRealm(realm: string) {
+    return this.findOne({ filter: { where: { realm } } });
   }
 }
 ```
+
+**Note:** When `@inject` is at param index 0, auto-injection is skipped (your `@inject` takes precedence).
+
 You would then register this repository in your `application.ts`: `this.repository(ConfigurationRepository);`
 
 ### Querying Data

package/wiki/get-started/quickstart.md

@@ -265,7 +265,7 @@ export class HelloController extends BaseController {
   })
   sayHello(c: Context) {
     // This looks just like Hono! Because it IS Hono under the hood.
-    return c.json({ message: 'Hello, World!' });
+    return c.json({ message: 'Hello, World!' }, HTTP.ResultCodes.RS_2.Ok);
   }
 
   // You can add more routes here:

package/wiki/references/base/controllers.md

@@ -65,7 +65,7 @@ export class MyFeatureController extends BaseController {
 
   @api({ configs: MyRouteConfig })
   getData(c: TRouteContext<typeof MyRouteConfig>) { // Return type is automatically inferred and validated
-    return c.json({ success: true });
+    return c.json({ success: true }, HTTP.ResultCodes.RS_2.Ok);
   }
 }
 ```
@@ -83,7 +83,7 @@ For convenience, `Ignis` provides decorator shortcuts for each HTTP method: Thes
 **Example using `@get` and `@post` with type inference:**
 
 ```typescript
-import { get, post, z, jsonContent, jsonResponse, Authentication, TRouteContext } from '@venizia/ignis';
+import { get, post, z, jsonContent, jsonResponse, Authentication, TRouteContext, HTTP } from '@venizia/ignis';
 
 // Define route configs as const for full type inference
 const USER_ROUTES = {
@@ -125,20 +125,20 @@ const USER_ROUTES = {
 
   @get({ configs: USER_ROUTES.listUsers })
   getAllUsers(c: TRouteContext<typeof USER_ROUTES.listUsers>) { // Return type is automatically inferred
-    return c.json([{ id: '1', name: 'John Doe' }]);
+    return c.json([{ id: '1', name: 'John Doe' }], HTTP.ResultCodes.RS_2.Ok);
   }
 
   @get({ configs: USER_ROUTES.getUser })
   getUserById(c: TRouteContext<typeof USER_ROUTES.getUser>) { // Return type is automatically inferred
     const { id } = c.req.valid('param'); // id is typed as string
-    return c.json({ id, name: 'John Doe' });
+    return c.json({ id, name: 'John Doe' }, HTTP.ResultCodes.RS_2.Ok);
   }
 
   @post({ configs: USER_ROUTES.createUser })
   createUser(c: TRouteContext<typeof USER_ROUTES.createUser>) { // Return type is automatically inferred
     const { name } = c.req.valid('json'); // name is typed as string
     const newUser = { id: '2', name };
-    return c.json(newUser, 201); // Return type is validated
+    return c.json(newUser, HTTP.ResultCodes.RS_2.Created); // Return type is validated
   }
 ```
 
@@ -171,17 +171,21 @@ export class HealthCheckController extends BaseController {
   @api({ configs: HEALTH_CHECK_ROUTES['/ping'] })
   ping(c: TRouteContext<typeof HEALTH_CHECK_ROUTES['/ping']>) { // Return type is automatically inferred
     const { message } = c.req.valid('json');
-    return c.json({ pong: message });
+    return c.json({ pong: message }, HTTP.ResultCodes.RS_2.Ok);
   }
 }
 ```
 
 ### Manual Route Definition Methods
 
-While decorator-based routing is available, the recommended way to define routes is by using the `defineRoute` and `bindRoute` methods inside the `binding()` method. This approach offers a clear and declarative syntax that keeps your route definitions organized and easy to manage.
+For advanced use cases or when you prefer a non-decorator approach, you can define routes manually using `defineRoute` and `bindRoute` methods inside the `binding()` method.
 
-:::tip Recommendation
-For better organization and a more declarative approach, we strongly recommend using `defineRoute` or `bindRoute` within the `binding()` method to define your controller's routes. This keeps all route definitions in one place, making your controller easier to read and maintain.
+:::tip When to Use Manual Definition
+Manual route definition is useful for:
+- Dynamically generating routes based on configuration
+- Conditional route registration (feature flags)
+- Developers who prefer non-decorator syntax (coming from Express/Fastify)
+- Complex routing logic that benefits from programmatic control
 :::
 
 #### `defineRoute`
@@ -291,17 +295,17 @@ This factory method returns a `BaseController` class that is already set up with
 
 **Note:** The returned class is dynamically named using `controller.name` from the options. This ensures that when registered with `app.controller()`, the class has a proper name for binding keys and debugging (e.g., `ConfigurationController` instead of an anonymous class).
 
-| Name | Method | Path | Description |
+| Route Name | Method | Path | Description |
 | :--- | :--- | :--- | :--- |
 | `count` | `GET` | `/count` | Get the number of records matching a filter. |
 | `find` | `GET` | `/` | Retrieve all records matching a filter. |
 | `findById` | `GET` | `/:id` | Retrieve a single record by its ID. |
 | `findOne` | `GET` | `/find-one` | Retrieve a single record matching a filter. |
 | `create` | `POST` | `/` | Create a new record. |
-| `updateById` | `PATCH` | `/:id` | Update a record by its ID. |
-| `updateAll` | `PATCH` | `/` | Update multiple records matching a filter. |
-| `deleteById` | `DELETE` | `/:id` | Delete a record by its ID. |
-| `deleteAll` | `DELETE` | `/` | Delete multiple records matching a filter. |
+| `updateById` | `PATCH` | `/:id` | Update a single record by its ID. |
+| `updateBy` | `PATCH` | `/` | Update multiple records matching a `where` filter. |
+| `deleteById` | `DELETE` | `/:id` | Delete a single record by its ID. |
+| `deleteBy` | `DELETE` | `/` | Delete multiple records matching a `where` filter. |
 
 ### `ICrudControllerOptions<EntitySchema>`
 
@@ -311,10 +315,30 @@ This factory method returns a `BaseController` class that is already set up with
 | `repository.name` | `string` | The binding key name of the repository associated with this entity (e.g., `'ConfigurationRepository'`). |
 | `controller.name` | `string` | A unique name for the generated controller (e.g., `'ConfigurationController'`). |
 | `controller.basePath`| `string` | The base path for all routes in this CRUD controller (e.g., `'/configurations'`). |
+| `controller.readonly` | `boolean` | If `true`, only read operations (find, findOne, findById, count) are generated. Write operations are excluded. Defaults to `false`. |
 | `controller.isStrict` | `boolean` | If `true`, query parameters like `where` will be strictly validated. Defaults to `true`. |
 | `controller.defaultLimit`| `number` | The default limit for `find` operations. Defaults to `10`. |
-| `schema` | `object` | An optional object to override the default Zod schemas for specific CRUD endpoints (e.g., `find`, `create`, `updateByIdRequestBody`). This allows for fine-grained control over the request and response validation and OpenAPI documentation. |
-| `doDeleteWithReturn` | `boolean` | If `true`, the `deleteById` and `deleteAll` endpoints will return the deleted record(s) in the response body. Defaults to `false`. |
+| `schema` | `object` | An optional object to override the default Zod schemas for specific CRUD endpoints. See schema options below. |
+| `doDeleteWithReturn` | `boolean` | If `true`, the `deleteById` and `deleteBy` endpoints will return the deleted record(s) in the response body. Defaults to `false`. |
+
+### Schema Override Options
+
+The `schema` option allows fine-grained control over request/response validation and OpenAPI documentation:
+
+| Schema Option | Description |
+| :--- | :--- |
+| `count` | Override response schema for count endpoint |
+| `find` | Override response schema for find endpoint |
+| `findOne` | Override response schema for findOne endpoint |
+| `findById` | Override response schema for findById endpoint |
+| `create` | Override response schema for create endpoint |
+| `createRequestBody` | Override request body schema for create endpoint |
+| `updateById` | Override response schema for updateById endpoint |
+| `updateByIdRequestBody` | Override request body schema for updateById endpoint |
+| `updateBy` | Override response schema for updateBy (bulk update) endpoint |
+| `updateByRequestBody` | Override request body schema for updateBy endpoint |
+| `deleteById` | Override response schema for deleteById endpoint |
+| `deleteBy` | Override response schema for deleteBy (bulk delete) endpoint |
 
 ### Example