sql-splitter 1.12.2

High-performance CLI tool for splitting large SQL dump files into individual table files
Documentation 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118

# Contributing to sql-splitter

Thanks for your interest in contributing! This document covers everything you need to get started.

## Development Setup

1. **Clone the repository**
   ```bash
   git clone https://github.com/helgesverre/sql-splitter.git
   cd sql-splitter
   ```

2. **Install Rust 1.70+**
   - All platforms: [rustup.rs](https://rustup.rs/)
   ```bash
   curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
   ```

3. **Build and test**
   ```bash
   cargo build --release
   cargo test
   ```

## Code Style

- Run `cargo fmt` before committing
- Run `cargo clippy` to check for issues
- Keep functions focused and small
- Add comments for non-obvious logic

## AI-Assisted Development

AI coding assistants are encouraged for contributing to this project. Tools like [Amp Code](https://ampcode.com), [Claude Code](https://claude.ai/code), Cursor, and similar assistants can significantly accelerate development.

### Quality Requirements

AI-generated code must meet the same standards as human-written code:

- **All tests must pass genuinely** - Tests verify actual behavior, not just compile
- **No stubbed tests** - Never use `todo!()`, `unimplemented!()`, or hardcoded expected values to make tests pass artificially
- **No skipped assertions** - Every test must assert meaningful behavior
- **Review critically** - Understand and verify all generated code before committing

### Feature Design Workflow

For new features or significant changes, follow this workflow:

1. **Check existing designs** - Review `docs/features/` for related design docs
2. **Write a design doc** - For new features, create `docs/features/FEATURE_NAME.md` (see `SAMPLE_FEATURE.md` for template)
3. **Implement in phases** - Break large features into phases as shown in the design doc
4. **Test thoroughly** - Add tests that verify the design requirements
5. **Reference in PR** - Link to the design doc in your pull request

### Modes of Work

When starting an AI session, consider which mode you're in:

| Mode | Purpose | Example |
|------|---------|---------|
| **Build** | New functionality | "Implement sample command (Phase 1)" |
| **Improve** | Refactor without changing behavior | "Extract sampler module" |
| **Sweep** | Fix related bugs | "Fix all INSERT parsing edge cases" |

This prevents scope creep and keeps AI contributions focused.

## Testing

- Run all tests: `cargo test`
- Run with output: `cargo test -- --nocapture`
- Run benchmarks: `cargo bench`

All PRs must pass tests. Add tests for new functionality.

## Benchmarking

```bash
# Run all benchmarks
cargo bench

# Run specific benchmark
cargo bench --bench parser

# With profiling (requires flamegraph)
cargo flamegraph --bench parser
```

## Pull Request Process

1. Fork the repository
2. Create a feature branch (`git checkout -b feature/my-feature`)
3. Make your changes
4. Run tests and linting:
   ```bash
   cargo fmt
   cargo clippy
   cargo test
   ```
5. Commit with a clear message
6. Push and open a PR

### PR Expectations

- Describe what the PR does and why
- Keep changes focused (one feature/fix per PR)
- Update documentation if needed
- Add tests for new functionality

## Reporting Issues

- Search existing issues first
- Include reproduction steps for bugs
- Include Rust version (`rustc --version`) and OS
- Be specific about expected vs actual behavior

## Questions?

Open an issue or start a discussion.