Strip openGemini/openGemini dependencies

[xuthus5]

The current cli relies on openGemini/openGemini, which results in a large build product. The cli needs to be streamlined.

[Mikkey-f]

Re: Issue #35 - Strip openGemini dependencies

Hi @xuthus5,

I've investigated this issue and identified the root cause along with a solution.

Problem Analysis

The export command encounters runtime errors during actual testing:

fatal error: index out of range

This occurs tell us current codes have some problems.

Solution: Query-Based Export

Rewrite the export functionality to use the query interface instead of direct file I/O:

Benefits:

• Significantly reduced binary size
• Improved stability
• Faster compilation
• Only requires opengemini-client-go client library

Feature Coverage:

• ✅ All filtering capabilities (database, measurement, time range, retention policy)
• ✅ All export formats (txt, csv, remote)
• ✅ Compression, progress tracking
• ✅ Resume capability (optional implementation)
• ❌ Offline export (when server is down)

Regarding Offline Export: This feature is not essential for CLI (rare use case in practice). MySQL/PostgreSQL CLI tools don't provide this either. If truly needed, it's better suited for a separate server-side tool.

Implementation Approach

Replace file path parameters with network connection parameters:

# Current approach
--data /path --wal /path --dbfilter mydb

# New approach  
--host localhost --port 8086 --database mydb

This will significantly simplify the code and improve maintainability.

I'm happy to implement this if you agree with this direction!

[Mikkey-f]

do you have some advice? If you have, please tell me know.

[xuthus5]

Backing up data via the file system is necessary, which typically occurs when the kernel fails to boot.

[xuthus5]

A better approach would be to analyze which modules the kernel depends on, and then extract the dependent kernel code and store it in this repository. What do you think?

[Mikkey-f]

I have an idea - what if we implement a dual-mode approach?

Primary mode: Online export (via HTTP API)

• Good enough for daily use
• Much smaller binary size
• More stable, no need to handle low-level file formats

Emergency mode: Offline export (direct file reading)

• Keep the current file reading functionality
• But compile on-demand using go build -tags offline
• Or simply create two separate tools: ts-cli and ts-recover

Benefits:

• No need to extract kernel code (maintenance cost would be too high, would need to sync on every version upgrade)
• Regular users get the lightweight version (10-20MB)
• Offline recovery scenarios use the full version (~80MB)
• Everyone gets what they need

Implementation is straightforward too - just use // +build offline to isolate the code, no major refactoring needed.

What do you think about this direction?

[Mikkey-f]

Do you think splitting it into two tools would be better?

[xuthus5]

Good idea, generate two build artifacts: one lightweight version that matches the current state, and another built using a tag.

[Mikkey-f]

sure, i will solve this issue in this way,thanks~