Data & Database Decorators

AxilJS data decorators describe how application code interacts with persistent storage. They express database operations, transaction boundaries, consistency requirements, entity mappings, and tenant isolation as semantic metadata.

The decorators describe intent; database and ORM consumers interpret that metadata to implement the required behavior without coupling application code to a specific database driver.

@tDatabase#

Declares the database operation semantics for a method.

import { tDatabase } from '@axiljs/decorator'
 
@tDatabase({ operation: 'read' })
async getUser(id: string) {}
 
@tDatabase({ operation: 'write', replica: 'primary' })
async updateUser(id: string, data: UpdateDto) {}

Options#

@tDatabase makes the intended database access pattern explicit. A runtime or ORM consumer can use this metadata to select an appropriate connection pool and enforce operation constraints.

@tTransaction#

Defines a database transaction boundary around a method.

import { tTransaction } from '@axiljs/decorator'
 
@tTransaction()
async transferFunds(from: string, to: string, amount: number) {}

Transaction configuration can include isolation, timeout, and propagation behavior:

@tTransaction({
  isolation: 'serializable',
  timeout: 5000,
})
async processPayment(orderId: string) {}

Options#

The transaction decorator expresses the boundary and requirements. The underlying transaction manager is responsible for implementing the actual database transaction.

@tIsolation#

Declares a minimum transaction isolation requirement.

Use @tIsolation when the isolation requirement needs to be expressed independently from the transaction boundary.

import { tIsolation } from '@axiljs/decorator'
 
@tIsolation('serializable')
async getBalance(accountId: string) {}

This allows infrastructure consumers to reason about isolation requirements separately from transaction configuration.

@tConsistent#

Declares the consistency guarantee required by an operation.

This is particularly useful in distributed systems where data may be replicated across multiple database nodes or read replicas.

import { tConsistent } from '@axiljs/decorator'
 
@tConsistent('strong')
async getBalance() {}
 
@tConsistent('eventual')
async getRecommendations() {}

Consistency Values#

The semantic requirement can be consumed by database routing or distributed data infrastructure to determine an appropriate read source.

@tReadOnly#

Declares that a method must not perform write operations.

import { tReadOnly } from '@axiljs/decorator'
 
@tReadOnly()
async generateReport() {}

An ORM or database consumer can use this metadata to reject write queries executed within the operation.

This is useful for reporting, analytics, query services, and other operations where mutation should be explicitly prohibited.

@tTenantIsolated#

Declares that database access must be scoped to the current tenant.

import { tTenantIsolated } from '@axiljs/decorator'
 
@tTenantIsolated()
async findAll() {
  return this.orderRepo.findAll()
}

A tenant-aware database consumer can apply the current tenant boundary to generated queries:

WHERE tenant_id = currentTenant

This makes tenant isolation an explicit data-access requirement rather than relying entirely on individual repository implementations.

@tTenantIsolated describes the isolation requirement. The database, ORM, or infrastructure consumer is responsible for enforcing it.

Entity Decorators

AxilJS also provides semantic decorators for describing database entities and their mappings.

@tEntity#

Declares a class as a database entity.

import {
  tEntity,
  tPrimaryKey,
  tColumn,
} from '@axiljs/decorator'
 
@tEntity({ table: 'users' })
class User {
  @tPrimaryKey()
  id: number
 
  @tColumn({ type: 'varchar', length: 255 })
  name: string
 
  @tColumn({ unique: true })
  email: string
}

The entity metadata describes how the application model maps to persistent storage.

@tColumn#

Maps a class property to a database column.

import { tColumn } from '@axiljs/decorator'
 
@tColumn({
  type: 'decimal',
  precision: 10,
  scale: 2,
})
price: number
 
@tColumn({ type: 'jsonb' })
metadata: Record<string, any>
 
@tColumn({ select: false })
password: string

Column metadata can describe storage types and constraints required by the database consumer.

@tPrimaryKey#

Marks a property as the entity's primary key.

import { tPrimaryKey } from '@axiljs/decorator'
 
@tPrimaryKey()
id: number

The resulting metadata can be used by an ORM or schema-management consumer when generating queries and persistence mappings.

@tRelation#

Declares a relationship between entities.

import { tRelation } from '@axiljs/decorator'
 
@tRelation({
  type: 'many-to-one',
  target: () => User,
})
author: User
 
@tRelation({
  type: 'one-to-many',
  target: () => Post,
  cascade: true,
})
posts: Post[]

Relation Types#

Relations remain semantic metadata, allowing the persistence layer to determine how relationships are represented and queried.

Full Entity Example

import {
  tEntity,
  tPrimaryKey,
  tColumn,
  tRelation,
} from '@axiljs/decorator'
 
@tEntity({ table: 'orders' })
class Order {
  @tPrimaryKey()
  id: number
 
  @tColumn({
    type: 'decimal',
    precision: 10,
    scale: 2,
  })
  total: number
 
  @tColumn({
    type: 'enum',
    default: 'pending',
  })
  status: string
 
  @tRelation({
    type: 'many-to-one',
    target: () => User,
  })
  customer: User
 
  @tRelation({
    type: 'one-to-many',
    target: () => OrderItem,
    cascade: true,
  })
  items: OrderItem[]
}

Entity decorators produce metadata that a persistence consumer can use for queries, migrations, and type-safe repositories. The same metadata can also be consumed by tooling such as database browsers, schema generators, and compliance systems.

Composing Data Semantics

Data decorators can be combined when an operation has multiple storage requirements.

import {
  tDatabase,
  tTransaction,
  tIsolation,
  tConsistent,
  tTenantIsolated,
} from '@axiljs/decorator'
 
@tDatabase({
  operation: 'write',
  replica: 'primary',
})
@tTransaction({
  isolation: 'serializable',
  timeout: 5000,
})
@tIsolation('serializable')
@tConsistent('strong')
@tTenantIsolated()
async transferFunds(
  fromAccount: string,
  toAccount: string,
  amount: number,
) {
  // Business logic
}

This separates the business operation from infrastructure implementation while making its data requirements explicit:

• The operation performs a write.
• The write is routed to the primary database.
• A transaction boundary is required.
• Serializable isolation is required.
• Strong consistency is required.
• Data access must remain tenant-isolated.

The consumer layer can interpret these semantics and translate them into the appropriate database, ORM, transaction, and routing behavior.

Data Decorator Reference