dpone-native-accel
dpone-native-accel is the optional provider package for dpone native-transfer
acceleration. It contains the certified MSSQL BCP native -> ClickHouse Native
block encoder and the direct ClickHouse Native TCP ingest backend.
The direct ingest backend sends pre-encoded ClickHouse Native blocks through the
Native TCP protocol without spawning clickhouse-client. native_tcp.backend: auto selects this backend when the provider is installed and certified;
backend: client keeps the subprocess fallback for compatibility benchmarks.
Optional provider package for dpone native-transfer acceleration.
The package exposes the stable provider boundary used by dpone[accel].
Backends declare certified capabilities before dpone can select them for
native_transfer.wire.acceleration.mode: auto|required.
The v0.74 provider includes a fused MSSQL BCP native -> ClickHouse Native block
encoder and a direct ClickHouse Native TCP insert backend. Direct insert uses a
native-protocol INSERT ... VALUES query plus protocol Data packets; it does
not shell out to clickhouse-client and does not materialize Python row
objects.
The legacy transcode() API continues to yield raw Native blocks. The dpone
runtime uses the additive transcode_batches() boundary, whose closed mapping
binds each block to the row count observed by the encoder before serialization;
raw bytes or malformed batch mappings fail closed and cannot produce successful
acceleration evidence.
Certification covers signed/unsigned integers, bool, Float32/Float64 finite
extremes, Decimal128/Decimal256 max/min scaled values, nullable decimals,
Unicode text, tabs/newlines, binary payloads, UUID, Date/Date32,
DateTime/DateTime64 precision, SQL Server time and datetimeoffset,
FixedString padding and oversize rejection, and NULL versus empty values.
LowCardinality, composite, and enum Native targets fail closed because they
require dictionary or nested serialization rather than scalar bytes.
Unsupported source layouts fall back to the reference path unless acceleration
is explicitly required.
1 maintainer
Release files for dpone-native-accel 0.79.0
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | |
|---|---|---|---|
| dpone_native_accel-0.79.0.tar.gz | 14.9 kB | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| dpone_native_accel-0.79.0-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 34.2 kB
Release files / dpone_native_accel-0.79.0.tar.gz
| Download URL | dpone_native_accel-0.79.0.tar.gz |
|---|---|
| Size | 14.9 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
96acd579069947b347998e9d80fab4d4117a274b4b5abba4774f7279bd6eb466
|
|
BLAKE2b-256 checksum How to use checksums |
4d6ecf651d6362d964892bd97ac83a71942865e6ebb2f8542491e6cdfb373c9e
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/6.1.0 CPython/3.13.13
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Sep 11, 2026.
Transparency logRelease files / dpone_native_accel-0.79.0-py3-none-any.whl
| Download URL | dpone_native_accel-0.79.0-py3-none-any.whl |
|---|---|
| Size | 19.3 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
4534430a4db9bae5fbf1be138399c48d8861d170f61816e6ad573fcad4fd59cb
|
|
BLAKE2b-256 checksum How to use checksums |
c82b8477ca33bcb5516e8bd9eb100ab3dad3de9057d23d6ba4d898aa7574febe
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/6.1.0 CPython/3.13.13
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Sep 11, 2026.
Transparency log
