EnhancedPostgRESTRepository
Overview
EnhancedPostgRESTRepository<T, K> è la classe finale che eredita ogni metodo CRUD/RPC/cache da BaseEnhancedRepository senza aggiungere logica. È pensata per essere istanziata una volta per tabella/entità, con path e keyName fissati nel costruttore.
class EnhancedPostgRESTRepository<T extends Record<string, unknown>, K>
extends BaseEnhancedRepository<T, K>
Rispetto a PostgRESTRepository, l'API è semplificata:
PostgRESTRepository | EnhancedPostgRESTRepository |
|---|---|
repo.read<User, number>('/users', 1, 'id') | repo.read(1) |
repo.update<User, number>('/users', 1, payload, 'id') | repo.update(1, payload) |
repo.delete<User, number>('/users', 1, 'id') | repo.delete(1) |
RepositoryFactory.create() che applica preset enterprise (cache 1h, JWT, background refresh) e semplifica la firma.Quando usarlo
- Hai una sola tabella da gestire per repository (caso standard DDD: un repository per aggregate root)
- Vuoi un'API CRUD minimale senza ripetere
pathekeyNamesu ogni chiamata - Hai bisogno di mantenere type safety completa su
<T, K>
Quando NON usarlo
- Devi accedere a path multipli sulla stessa istanza → usa direttamente
PostgRESTRepository - Devi aggiungere metodi custom di dominio (es.
findByEmail) → estendiBaseEnhancedRepository
Costruttore
new EnhancedPostgRESTRepository<T, K>(options: EnhancedRepositoryOptions<T>)
EnhancedRepositoryOptions<T>
| Campo | Tipo | Default | Descrizione |
|---|---|---|---|
baseUrl | string | — | URL base dell'API PostgREST |
path | string | — | Path della tabella (può includere query params: '/users?select=id,name') |
keyName | keyof T | — | Nome della colonna chiave primaria |
isAuthRequired | boolean? | false | Includi token nelle richieste |
useCache | boolean? | false | Abilita caching read |
cacheTTL | number? | — | TTL cache in millisecondi |
useBackgroundRefresh | boolean? | true | Refresh in background della cache |
schema | string? | 'public' | Schema PostgreSQL |
API
I metodi sono tutti ereditati da BaseEnhancedRepository — l'API completa è documentata lì.
| Metodo | Signature |
|---|---|
create | (element: Partial<T>): Promise<T | undefined> |
createOrUpdate | (element: Partial<T>): Promise<T | undefined> |
read | (key: K, forceRefresh?: boolean): Promise<T | undefined> |
readAll | (filters?: FilterCriteria<T>, forceRefresh?: boolean): Promise<T[]> |
update | (key: K, element: Partial<T>): Promise<T | undefined> |
delete | (key: K): Promise<T | undefined> |
createMany | (elements: Partial<T>[]): Promise<T[] | undefined> |
updateMany | (element: Partial<T>, filters?): Promise<T[] | undefined> |
deleteMany | (keys: K[]): Promise<T[] | undefined> |
rpcGet / rpcPost / rpcRawGet / rpcRawPost | RPC delegati al PostgRESTRepository interno |
invalidateCache(key) / invalidateAllCache() | Gestione cache |
prefetchRecord(key) / prefetchRecords(filters?) | Prefetch background |
Esempio
import { EnhancedPostgRESTRepository } from '@pzeta/postgrest'
interface User extends Record<string, unknown> {
idutente: number
nome: string
email: string
status: 'active' | 'inactive'
}
// Istanziazione diretta (raro — preferisci RepositoryFactory)
const userRepo = new EnhancedPostgRESTRepository<User, number>({
baseUrl: 'https://api.example.com',
path: '/utenti',
keyName: 'idutente',
isAuthRequired: true,
useCache: true,
cacheTTL: 3_600_000,
schema: 'app',
})
// API minimale
const nuovo = await userRepo.create({ nome: 'Mario', email: 'mario@example.com' })
const tutti = await userRepo.readAll({ status: { operator: 'eq', value: 'active' } })
const uno = await userRepo.read(1)
await userRepo.update(1, { nome: 'Mario Rossi' })
await userRepo.delete(1)
Path con select PostgREST
Il path può includere query parameters statici — vengono preservati su ogni operazione:
const userRepo = new EnhancedPostgRESTRepository<User, number>({
baseUrl,
path: '/utenti?select=idutente,nome,email,ruolo(nome)',
keyName: 'idutente',
})
// Ogni read/readAll includerà automaticamente il select
const utenti = await userRepo.readAll()
rpcGet e rpcPost di BaseEnhancedRepository usano this.pathsenza i query args. Per RPC con parametri controllati usa rpcRawGet/rpcRawPost specificando esplicitamente il nome della funzione.Cross-reference
RepositoryFactory— modo idiomatico per creare istanze con presetBaseEnhancedRepository— classe base con tutti i metodiPostgRESTRepository— implementazione concreta usata internamenteFilterCriteria— operatori filtro PostgREST
CrudRepositoryBase
Classe base astratta che definisce il contratto CRUD implements ICrudRepository — punto di estensione per backend non-PostgREST mantenendo l'API uniforme.
PostgRESTRepository
Repository CRUD core con supporto completo PostgREST — CRUD, bulk, RPC, paginazione cursor-based, caching, multi-schema e prefetch proattivo.