paw-persistence-contracts-layer

Design persistence contracts for PAW applications with JDBC and JPA abstraction.

9|Updated Apr 14, 2026

Search Tags:#jpa #batch-operations #layering #jdbc #n-plus-one #dao-contracts #persistence-abstraction

Ready to run

npx skills add https://github.com/keodubo/PAW-Wiki --skill paw-persistence-contracts-layer

💬 Prompt for ChatGPT / Claude Chat▼

Please help me install this Agent Skill.
Skill: paw-persistence-contracts-layer
Source: https://github.com/keodubo/PAW-Wiki/tree/main/skills/paw-persistence-contracts-layer
Command: npx skills add https://github.com/keodubo/PAW-Wiki --skill paw-persistence-contracts-layer

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

This skill eliminates common pitfalls in persistence layer development by enforcing strict DAO contract design rules, preventing implementation leakage and N+1 queries across PAW application stages.

Core Features & Use Cases

Contract Abstraction Guards: Ensures DAO interfaces remain free of JDBC/JPA implementation details while maintaining TP1/TP2 compatibility.
Batch Operation Patterns: Identifies and implements batch contracts to eliminate database query loops in service layers.
Behavior-Oriented Naming: Promotes method signatures like findReassignableForReservations over technical naming conventions.
Use Case: When implementing a new restaurant reservation feature, use this skill to design ReservationDao contracts that abstract JDBC row mappers while supporting batch reservation updates.

Quick Start

Use this skill to audit existing DAO contracts for N+1 query vulnerabilities and implementation leakage.

Frequently Asked Questions about paw-persistence-contracts-layer

High-intent search queries and answers about installing and using this skill.

FAQPage Schema

How do I prevent N+1 query problems when designing DAO contracts?▼

Design batch operation patterns directly into DAO contracts so related entities are fetched in a single query rather than looping through individual requests, eliminating database query loops in service layers.

What is the best way to abstract JDBC implementation details from DAO interfaces?▼

Abstract JDBC implementation details from DAO interfaces by enforcing strict contract abstraction guards that keep implementation details like row mappers out of the interface. This maintains TP1 JDBC compatibility while ensuring the service layer remains decoupled from the underlying persistence technology.

How do I design JPA-backed persistence contracts for batch operations?▼

Design JPA-backed persistence contracts for batch operations by defining TP2 contracts that enforce behavior-oriented naming and batch patterns. This involves creating DAO interfaces that support batch reservation updates while abstracting JPA implementation specifics away from the service layer.

Why does implementation leakage happen in persistence layer design?▼

Implementation leakage happens in persistence layer design when DAO interfaces expose JDBC or JPA-specific details like row mappers or entity annotations. This breaks abstraction discipline between service layers and persistence implementations, creating tight coupling and making the system harder to maintain.

Can I use this persistence abstraction approach for both JDBC and JPA layers?▼

Yes, this persistence abstraction approach supports both TP1 JDBC contracts and TP2 JPA-backed contracts. It enforces naming conventions and batch operation patterns across both implementations while keeping behavior-oriented method signatures free of technology-specific details.

How do I audit existing DAO contracts for implementation leakage and N+1 vulnerabilities?▼

Audit existing DAO contracts for implementation leakage and N+1 vulnerabilities by checking for JDBC or JPA types in interface signatures and identifying methods that trigger queries inside loops. This skill applies compile-time verification to catch these issues during contract design.