# sea-query-hyperdb Development
Contributor guide for the `sea-query-hyperdb` crate.
## Dialect Implementation
`HyperQueryBuilder` implements all sea-query backend traits (`QueryBuilder`,
`SchemaBuilder`, `GenericBuilder`, and their sub-traits) by delegating every
method to `PostgresQueryBuilder`. This is a deliberate design choice: HyperDB's
SQL dialect is currently PostgreSQL-compatible for identifier quoting, placeholder
syntax (`$1, $2, ...`), operator precedence, and DDL/DML syntax.
The delegation is explicit per-method rather than using a blanket `Deref` or
macro, so that individual methods can be overridden independently as the dialect
diverges. See the doc comment on `HyperQueryBuilder` in `src/lib.rs` for the
full rationale.
## When Hyper Diverges from PostgreSQL
As HyperDB adds dialect-specific features, override individual trait methods
to emit Hyper-specific SQL while leaving the rest delegated. Likely candidates:
- **Type names** -- Hyper may introduce types not in PostgreSQL
- **Function syntax** -- Hyper-specific built-in functions
- **DDL extensions** -- Hyper-specific table or column options
When adding an override:
1. Override the relevant method on the appropriate trait impl
2. Add a unit test that asserts the Hyper output differs from `PostgresQueryBuilder`
3. Document the divergence in the `HyperQueryBuilder` struct doc comment
## Testing
All tests live in the `#[cfg(test)] mod tests` block in `src/lib.rs`. The test
strategy verifies that `HyperQueryBuilder` produces identical SQL to
`PostgresQueryBuilder` for all standard operations (SELECT, INSERT, UPDATE,
DELETE, CREATE TABLE).
Run tests:
```bash
cargo test -p sea-query-hyper
```
Run the example:
```bash
cargo run -p sea-query-hyperdb --example basic_usage
```
When Hyper-specific overrides are added, tests should assert both that the
override produces the expected Hyper-specific SQL and that non-overridden
operations still match `PostgresQueryBuilder`.